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 2 of 27 — ← Prev page 1 [2] 3 4 … 27 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-19 11:51 -0800 |
| Message-ID | <165683fa-9138-459a-8f72-38bba7aa2feb@googlegroups.com> |
| In reply to | #104221 |
On Sunday, February 19, 2017 at 2:26:09 PM UTC-5, GOTHIER Nathan wrote: > On Sun, 19 Feb 2017 13:10:04 -0500 > "James R. Kuyper" <jameskuyper@verizon.net> wrote: > > > Again - who said they were Christians? And most of them are working for > > free. Even most of the ones with corporate support are only having the > > membership fees and travel expenses covered; they don't get paid for the > > time they spend on committee work. If you find it hard to imagine that > > anyone would ever do any volunteer work (or if you imagine that someone > > has to be a Christian to be a volunteer), you're sadly mistaken. You > > must have lived your life surrounded by some pretty awful people. > > I think you have been hurt by the word "Christian". ... Only confused by it. I get the impression you're speaking from the perspective of believing that everyone is, at least nominally, a Christian, even if a corrupted one, and that therefore anyone "pretending" to volunteer must be doing so in order to appear properly "Christian". That attitude is out of touch with reality, where there's lots of people who have no interest in appearing to be Christian, regardless of whether it's a good Christian or a bad one. > ... For me talking about > Christian in comp.lang.c is a word game and a rhetorical figure for > volunteering in a world where humanity is fully corrupted by money and power. I'm sorry you think that you live in such a world. While a deplorable amount of such corruption does exist in the world I live in, it is very far from universal. Personally, I'm more worried about the corrupting influence of bigotry than of money. Bigotry is apparently a far bigger problem than I would have thought it was a year ago.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-19 12:26 -0800 |
| Message-ID | <lny3x2lyfn.fsf@kst-u.example.com> |
| In reply to | #104221 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Sun, 19 Feb 2017 13:10:04 -0500
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
>> Again - who said they were Christians? And most of them are working for
>> free. Even most of the ones with corporate support are only having the
>> membership fees and travel expenses covered; they don't get paid for the
>> time they spend on committee work. If you find it hard to imagine that
>> anyone would ever do any volunteer work (or if you imagine that someone
>> has to be a Christian to be a volunteer), you're sadly mistaken. You
>> must have lived your life surrounded by some pretty awful people.
>
> I think you have been hurt by the word "Christian". For me talking about
> Christian in comp.lang.c is a word game and a rhetorical figure for
> volunteering in a world where humanity is fully corrupted by money and power.
That's not what that word means. What it does mean is not relevant here
in comp.lang.c.
>> Nor is there any shame in volunteering, and many people do.
>
> Indeed, however I have to confess I have no faith in humanity anymore.
I'm sorry to hear that, but we discuss the C programming language here.
Attempting to discuss religion here will either lead to long off-topic
discussions or will land you in multiple killfiles, quite possibly both.
Please stop.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-02-19 21:23 +0000 |
| Subject | Getting yourself killfiled (Was: Is this valid C?) |
| Message-ID | <o8d2c4$bp9$1@news.xmission.com> |
| In reply to | #104227 |
In article <lny3x2lyfn.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: ... >I'm sorry to hear that, but we discuss the C programming language here. >Attempting to discuss religion here will either lead to long off-topic >discussions or will land you in multiple killfiles, quite possibly both. You say that as if it was a bad thing. Being killfiled by Keith (and those similarly minded) is a Good Thing. It means that you won't have to deal with his dorky responses to your posts. That can only be to the good. Quite seriously, killfiles are good things. They allow multiple types of personalities to occupy the same space and not get in each other's way. (Yes, I know Keith will probably never read this - but others will. And if you quote it - and Kiks hasn't KF'd you - then he will benefit as well) -- A pervert, a racist, and a con man walk into a bar... Bartender says, "What will you have, Donald!"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-19 11:23 +0000 |
| Message-ID | <o8bv3d$dg8$1@dont-email.me> |
| In reply to | #104165 |
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.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-19 07:33 -0800 |
| Message-ID | <lnfujanqkz.fsf@kst-u.example.com> |
| 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?
No, no, and maybe, respectively.
In the first, A, B, and C are array expressions, but they're operands
of the commma operator so they decay to pointer expressions, making
(A,B,C) a pointer expression.
In (x?B:C) (fixed typo), B and C are array expressions, but they're
operands of the conditional operator so they decay to pointer
expressions, making (x?B:C) a pointer expression.
D[i] *is* an array expression. It may or may not decay to a pointer
expression, depending on its context.
Whether an array expression decays to a pointer expression is
determined entirely by its context, specifically whether or not
it's the (immediate) operand of a unary `sizeof` or `&` operator
(setting aside the string literal initializer case).
> All, including S.C, can have [j] appended, and effect in all cases is to
> index what had been declared as an actual array.
As you surely know, the indexing operator is applied to a pointer
expression, not an array expression. (Of course that pointer
expression is often a decayed array expression).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-19 15:35 +0000 |
| Message-ID | <87shnab3c5.fsf@bsb.me.uk> |
| 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?
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 ?:
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. That would make (x?B:C) legal
because B and C are then really expressions with compatible pointer
types. But if that's the case then (x,C) is also an expression with
pointer type and I'd expect that conversion to a pointer would also be
suppressed by sizeof.
When I first started following this thread, I thought the issue might be
related to lvalues since nether (x,C) not (X?B:C) are lvalue
expressions. Interestingly, in C90, the array to pointer conversion is
specifically described as converting array lvalues so there is nothing
for sizeof to suppress in sizeof (x,C) and the conversion happens only
in contexts where (x,C) is evaluated.
In C99 and C11 that sentence has been amended to remove the word lvalue
so it applies to all expressions with array type. It's certainly true
that the conversion happens for some other non-lvalue expressions with
(apparently) array types. For example, after
struct S { char C[10]; } S;
struct S f(void) { return S; }
the epression f().C converts to a pointer as expected and sizeof f().C
suppresses the conversion. (In C99 and C11 xxx.member is an lvalue if
xxx is one and function call expressions are not. In C90 it's unstated
if f() is an lvalue though it probably isn't. gcc and clang (correctly,
I think) refuse to convert f().C to a pointer in any context in C90
mode.
Anyway, sadly I'm posting only to express some confusion rather than
explanation.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-19 19:42 +0000 |
| Message-ID | <8737faarwc.fsf@bsb.me.uk> |
| In reply to | #104195 |
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 ?:
>
> 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. That would make (x?B:C) legal
> because B and C are then really expressions with compatible pointer
> types. But if that's the case then (x,C) is also an expression with
> pointer type and I'd expect that conversion to a pointer would also be
> suppressed by sizeof.
This is not a helpful contribution! Please ignore it (though it's
probably too late for that). The only correct part is the part about
the change in wording from C90 and that only muddies the waters.
You have to distinguish between the type of an expression and the type
is might be converted to in the context.
The only oddity is the notion of being an immediate operand of sizeof.
Comparing `sizeof (S.C)` and `sizeof (x,C)` one might imagine a parse
tree where C (respectively an array member and a declared array) are
neither the direct operand of sizeof.
The explanation is that the `C` in `S.C` is not an expression (it's just
an identifier). The only expression that can be an operand to sizeof is
the whole S.C.
> When I first started following this thread, I thought the issue might be
> related to lvalues since nether (x,C) not (X?B:C) are lvalue
> expressions. Interestingly, in C90, the array to pointer conversion is
> specifically described as converting array lvalues so there is nothing
> for sizeof to suppress in sizeof (x,C) and the conversion happens only
> in contexts where (x,C) is evaluated.
>
> In C99 and C11 that sentence has been amended to remove the word lvalue
> so it applies to all expressions with array type. It's certainly true
> that the conversion happens for some other non-lvalue expressions with
> (apparently) array types. For example, after
>
> struct S { char C[10]; } S;
> struct S f(void) { return S; }
>
> the epression f().C converts to a pointer as expected and sizeof f().C
> suppresses the conversion. (In C99 and C11 xxx.member is an lvalue if
> xxx is one and function call expressions are not. In C90 it's unstated
> if f() is an lvalue though it probably isn't. gcc and clang (correctly,
> I think) refuse to convert f().C to a pointer in any context in C90
> mode.
>
> Anyway, sadly I'm posting only to express some confusion rather than
> explanation.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-19 12:04 -0800 |
| Message-ID | <ln37fane0p.fsf@kst-u.example.com> |
| In reply to | #104195 |
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.
> That would make (x?B:C) legal
> because B and C are then really expressions with compatible pointer
> types. But if that's the case then (x,C) is also an expression with
> pointer type and I'd expect that conversion to a pointer would also be
> suppressed by sizeof.
(x,C) is invalid because x and C are of integer and pointer type,
respectively.
`(A,B)` is of pointer type; the array subexpressions are operands of the
comma operator, so they decay. `sizeof (A,B)` is perfectly valid, and
yields the size of an int* pointer. A and B are still not operands of
sizeof; only the parenthesized expression `(A,B)` is, and it's already
of pointer type. The sizeof operator doesn't "reach into" the
expression `(A,B)`, apply itself to the subexpressions `A` and `B`, and
inhibit their array-to-pointer conversions.
> When I first started following this thread, I thought the issue might be
> related to lvalues since nether (x,C) not (X?B:C) are lvalue
> expressions. Interestingly, in C90, the array to pointer conversion is
> specifically described as converting array lvalues so there is nothing
> for sizeof to suppress in sizeof (x,C) and the conversion happens only
> in contexts where (x,C) is evaluated.
>
> In C99 and C11 that sentence has been amended to remove the word lvalue
> so it applies to all expressions with array type. It's certainly true
> that the conversion happens for some other non-lvalue expressions with
> (apparently) array types. For example, after
>
> struct S { char C[10]; } S;
> struct S f(void) { return S; }
>
> the epression f().C converts to a pointer as expected and sizeof f().C
> suppresses the conversion. (In C99 and C11 xxx.member is an lvalue if
> xxx is one and function call expressions are not. In C90 it's unstated
> if f() is an lvalue though it probably isn't. gcc and clang (correctly,
> I think) refuse to convert f().C to a pointer in any context in C90
> mode.
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.
> Anyway, sadly I'm posting only to express some confusion rather than
> explanation.
I hope I've helped clear up some of it.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-19 20:51 +0000 |
| Message-ID | <87wpclaoqs.fsf@bsb.me.uk> |
| 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.
Yes, I know! I was getting distracted by the use of the definite
article as if expressions had a single type based on their form when (as
we all know) it's the form and the context. (The definite article is OK
provided the form *and* context are know.)
> 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.
Yes. It's easy to read it as if it's an "evaluation" conversion but of
course it's not. `B` *is* and expression of array type in some context
and it *is* an expression with pointer type in others.
>
>> That would make (x?B:C) legal
>> because B and C are then really expressions with compatible pointer
>> types. But if that's the case then (x,C) is also an expression with
>> pointer type and I'd expect that conversion to a pointer would also be
>> suppressed by sizeof.
>
> (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.
> `(A,B)` is of pointer type; the array subexpressions are operands of the
> comma operator, so they decay. `sizeof (A,B)` is perfectly valid, and
> yields the size of an int* pointer. A and B are still not operands of
> sizeof; only the parenthesized expression `(A,B)` is, and it's already
> of pointer type. The sizeof operator doesn't "reach into" the
> expression `(A,B)`, apply itself to the subexpressions `A` and `B`, and
> inhibit their array-to-pointer conversions.
Agreed. What's bugging BartC (and what prompted my incoherent rambling)
is that sizeof (S.C) and sizeof (S,C) look so similar. (The context
being an object S with an array member called C and a declared array
called C). He's probably built a parse tree where both look exactly the
same and he's planning to make sizeof "reach into" the operand to see
what form it takes.
But that's probably the wrong way to handle it. In sizeof (S,C), the
expression C is adjusted (I prefer your term to converted) to a pointer
because C is declared to be an array and the context permits (or
requires if you like) the adjustment. It's permitted because it's a
expression in its own right -- only expressions get so adjusted.
In sizeof (S.C), the C is just a member name. That C (on it's own) is
not an expression so it can not have its type adjusted in *any* context.
The only thing that is an expression is S.C as a whole and that *is* an
immediate operand to sizeof. The fact that one might represent S.C as
an expression node in a tree just like (S,C) is simple a convenience.
The parts of S.C are not expressions -- only the left part and the whole
thing are expressions.
>> When I first started following this thread, I thought the issue might be
>> related to lvalues since nether (x,C) not (X?B:C) are lvalue
>> expressions. Interestingly, in C90, the array to pointer conversion is
>> specifically described as converting array lvalues so there is nothing
>> for sizeof to suppress in sizeof (x,C) and the conversion happens only
>> in contexts where (x,C) is evaluated.
>>
>> In C99 and C11 that sentence has been amended to remove the word lvalue
>> so it applies to all expressions with array type. It's certainly true
>> that the conversion happens for some other non-lvalue expressions with
>> (apparently) array types. For example, after
>>
>> struct S { char C[10]; } S;
>> struct S f(void) { return S; }
>>
>> the epression f().C converts to a pointer as expected and sizeof f().C
>> suppresses the conversion. (In C99 and C11 xxx.member is an lvalue if
>> xxx is one and function call expressions are not. In C90 it's unstated
>> if f() is an lvalue though it probably isn't. gcc and clang (correctly,
>> I think) refuse to convert f().C to a pointer in any context in C90
>> mode.
>
> 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.)
>> Anyway, sadly I'm posting only to express some confusion rather than
>> explanation.
>
> I hope I've helped clear up some of it.
Yes, thanks.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-19 22:23 +0000 |
| Message-ID | <o8d5p6$s5l$1@dont-email.me> |
| In reply to | #104230 |
On 19/02/2017 20:51, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: >> `(A,B)` is of pointer type; the array subexpressions are operands of the >> comma operator, so they decay. `sizeof (A,B)` is perfectly valid, and >> yields the size of an int* pointer. A and B are still not operands of >> sizeof; only the parenthesized expression `(A,B)` is, and it's already >> of pointer type. The sizeof operator doesn't "reach into" the >> expression `(A,B)`, apply itself to the subexpressions `A` and `B`, and >> inhibit their array-to-pointer conversions. > > Agreed. What's bugging BartC (and what prompted my incoherent rambling) > is that sizeof (S.C) and sizeof (S,C) look so similar. (The context > being an object S with an array member called C and a declared array > called C). He's probably built a parse tree where both look exactly the > same and he's planning to make sizeof "reach into" the operand to see > what form it takes. > > But that's probably the wrong way to handle it. In sizeof (S,C), the > expression C is adjusted (I prefer your term to converted) to a pointer > because C is declared to be an array and the context permits (or > requires if you like) the adjustment. It's permitted because it's a > expression in its own right -- only expressions get so adjusted. > > In sizeof (S.C), the C is just a member name. That C (on it's own) is > not an expression so it can not have its type adjusted in *any* context. > The only thing that is an expression is S.C as a whole and that *is* an > immediate operand to sizeof. The fact that one might represent S.C as > an expression node in a tree just like (S,C) is simple a convenience. > The parts of S.C are not expressions -- only the left part and the whole > thing are expressions. It's not just S.C. The operators that can yield array types that would need pointer adjustment (apart from just the name of an array object), are "*", ".", "->" and "[]". And those last three can also be reduced to a single "*" operation. The method I'm trying is to do the pointer adjustment anyway, whenever an array type comes up, but to mark that AST node with information that allows the original array size to recovered, /if/ it ends up as the immediate operand of sizeof (or of & and so on). But that only happens with certain selected kinds of operators, such as "*", but not comma or ?:. This is according to observed behaviour rather than wording of the language reference which is none too clear. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-19 14:48 -0800 |
| Message-ID | <176093d8-deb4-435a-ba26-a3f9d88ef504@googlegroups.com> |
| In reply to | #104236 |
On Sunday, February 19, 2017 at 5:23:24 PM UTC-5, Bart wrote: ... > It's not just S.C. The operators that can yield array types that would > need pointer adjustment (apart from just the name of an array object), > are "*", ".", "->" and "[]". And those last three can also be reduced to > a single "*" operation. > > The method I'm trying is to do the pointer adjustment anyway, whenever > an array type comes up, but to mark that AST node with information that > allows the original array size to recovered, /if/ it ends up as the > immediate operand of sizeof (or of & and so on). > > But that only happens with certain selected kinds of operators, such as > "*", but not comma or ?:. This is according to observed behaviour rather > than wording of the language reference which is none too clear. The comma and ?: operators have a result which is of a type compatible with the type of the second operand, and usually the same as that type. Since the array=>pointer conversion always applies to those operands, they never have a result that has an array type. Similar arguments can be applied to most of the other operators The ., ->, *, and [] operators, however, are all capable of having a result of array type. So are string literals and compound literals.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 00:36 +0000 |
| Message-ID | <o8ddib$m86$1@dont-email.me> |
| In reply to | #104238 |
On 19/02/2017 22:48, jameskuyper@verizon.net wrote: > On Sunday, February 19, 2017 at 5:23:24 PM UTC-5, Bart wrote: >> But that only happens with certain selected kinds of operators, such as >> "*", but not comma or ?:. This is according to observed behaviour rather >> than wording of the language reference which is none too clear. > > The comma and ?: operators have a result which is of a type compatible with the type of the second operand, and usually the same as that type. Since the array=>pointer conversion always applies to those operands, they never have a result that has an array type. Similar arguments can be applied to most of the other operators The ., ->, *, and [] operators, however, are all capable of having a result of array type. So are string literals and compound literals. That didn't seem right at first: I usually think of a comma operator having multiple operands rather than two. Then the sequence (a,b,c,d) has a type corresponding to that of d, the last element. The a?b:c operator I'd assumed had a type corresponding to the more dominant of b and c, similar to what happens with basic arithmetical operators. But you're right in a saying an array type would have difficultly making its way out of these operators. Yet, it isn't completely obvious why the effect of sizeof couldn't have reached into a comma expression and effected the last element. Or worked with ?: (for which purpose, the b and c operands would have needed to be compatible arrays). Other than because the standard says it doesn't (and it wouldn't have been that useful anyway). --bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-20 09:58 +0100 |
| Message-ID | <o8eavg$l6t$1@dont-email.me> |
| In reply to | #104247 |
On 20/02/17 01:36, BartC wrote: > On 19/02/2017 22:48, jameskuyper@verizon.net wrote: >> On Sunday, February 19, 2017 at 5:23:24 PM UTC-5, Bart wrote: > >>> But that only happens with certain selected kinds of operators, such as >>> "*", but not comma or ?:. This is according to observed behaviour rather >>> than wording of the language reference which is none too clear. >> >> The comma and ?: operators have a result which is of a type compatible >> with the type of the second operand, and usually the same as that >> type. Since the array=>pointer conversion always applies to those >> operands, they never have a result that has an array type. Similar >> arguments can be applied to most of the other operators The ., ->, *, >> and [] operators, however, are all capable of having a result of array >> type. So are string literals and compound literals. > > That didn't seem right at first: I usually think of a comma operator > having multiple operands rather than two. Then the sequence (a,b,c,d) > has a type corresponding to that of d, the last element. The comma operator has only two operands, but you can chain them like this if you want. > > The a?b:c operator I'd assumed had a type corresponding to the more > dominant of b and c, similar to what happens with basic arithmetical > operators. That is correct, if b and c are arithmetic types - the usual arithmetic conversions apply. So (1 ? 2 : 3.5) has type double. In the context of dealing with pointers, the second and third operands of the conditional operator need to be "pointers to qualified or unqualified versions of compatible types". So AFAIUI James is correct but a little misleading in saying the result is "a type compatible with the type of the second operand" - /both/ the second and third operands need to be compatible. > > But you're right in a saying an array type would have difficultly making > its way out of these operators. Yet, it isn't completely obvious why the > effect of sizeof couldn't have reached into a comma expression and > effected the last element. Or worked with ?: (for which purpose, the b > and c operands would have needed to be compatible arrays). Other than > because the standard says it doesn't (and it wouldn't have been that > useful anyway). > The rules about array to pointer decay were made based on what the language designers thought would be most useful and what would be efficient to implement. It means that arrays are treated inconsistently with other types - and you are correct that they could have been treated differently. Ultimately, it is simply how C works, for good or for bad.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-20 09:14 -0800 |
| Message-ID | <cbc38036-9e8c-40bd-823c-9847aa1da57e@googlegroups.com> |
| In reply to | #104247 |
On Sunday, February 19, 2017 at 7:36:19 PM UTC-5, Bart wrote: > On 19/02/2017 22:48, jameskuyper@verizon.net wrote: > > On Sunday, February 19, 2017 at 5:23:24 PM UTC-5, Bart wrote: > > >> But that only happens with certain selected kinds of operators, such as > >> "*", but not comma or ?:. This is according to observed behaviour rather > >> than wording of the language reference which is none too clear. > > > > The comma and ?: operators have a result which is of a type compatible with > > the type of the second operand, and usually the same as that type. Since > > the array=>pointer conversion always applies to those operands, they never > > have a result that has an array type. Similar arguments can be applied to > > most of the other operators The ., ->, *, and [] operators, however, are > > all capable of having a result of array type. So are string literals and > > compound literals. > > That didn't seem right at first: I usually think of a comma operator > having multiple operands rather than two. Then the sequence (a,b,c,d) > has a type corresponding to that of d, the last element. Do you also think of the addition operator as having multiple operands, rather than just two? a+b+c+d is syntactically exactly the same type of thing as a,b,c,d. You might be able to get away thinking of things that way, depending upon precisely how you think about the details. With the binary + operator, I'm sure that treating a series of +'s as a single operator with multiple operands would sometimes produce incorrect results involving the way that promotion, conversions, rounding, overflow, and loss of precision are handled. Since the last operand of a chained series of comma expressions is the only one that matters, you won't run into those problems. However, I think you're better off thinking of the comma operator the way that the standard defines it, as a binary operator. > The a?b:c operator I'd assumed had a type corresponding to the more > dominant of b and c, similar to what happens with basic arithmetical > operators. I hadn't wanted to get into the details of the precise rules for determining the type, I just wanted to make the point that it's never an array type. In an attempt to simplify my statement, I ended up with it not being quite correct. When the second and third operands are both of arithmetic type, ?: does apply the usual arithmetic conversions (6.5.15p2). Note that the result of those conversions is not necessarily the same as the type of either of the last two operands. For instance, if one is double, and the other is long _Complex, the result has the type double _Complex. Similarly, on an implementation where LONG_MAX < UINT_MAX , then if one operand is long and the other is unsigned int, the result is unsigned long (6.3.1.8p1). > But you're right in a saying an array type would have difficultly making > its way out of these operators. Yet, it isn't completely obvious why the > effect of sizeof couldn't have reached into a comma expression and > effected the last element. Because that would not have been useful. K&R were trying to define a useful language. The implicit conversion from an array type to a pointer to the first argument was introduced precisely because it was convenient in typical contexts, because without that rule there'd be a lot of need to write things like &font_list[0].. However, sizeof is not one of the contexts where that conversion would be convenient. When using sizeof(array), you are usually interested in the size of the array itself, and not the size of the corresponding pointer. And, if you need the size of the pointer, you can always write sizeof(&array[0]). If sizeof were not an exception to the pointer conversion rule, there would be no way to get the size of the array itself.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-20 12:17 -0500 |
| Message-ID | <a84bfa90-aa4a-03e8-eb6e-1d81171b9c15@verizon.net> |
| In reply to | #104273 |
On 02/20/2017 12:14 PM, jameskuyper@verizon.net wrote: ... > Note that the result of those conversions is not necessarily the same as the > type of either of the last two operands. For instance, if one is double, and > the other is long _Complex, the result has the type double _Complex. "long" should have been "float" in that sentence.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-19 23:16 +0000 |
| Message-ID | <87mvdhai0d.fsf@bsb.me.uk> |
| In reply to | #104236 |
BartC <bc@freeuk.com> writes: > On 19/02/2017 20:51, Ben Bacarisse wrote: >> Keith Thompson <kst-u@mib.org> writes: > >>> `(A,B)` is of pointer type; the array subexpressions are operands of the >>> comma operator, so they decay. `sizeof (A,B)` is perfectly valid, and >>> yields the size of an int* pointer. A and B are still not operands of >>> sizeof; only the parenthesized expression `(A,B)` is, and it's already >>> of pointer type. The sizeof operator doesn't "reach into" the >>> expression `(A,B)`, apply itself to the subexpressions `A` and `B`, and >>> inhibit their array-to-pointer conversions. >> >> Agreed. What's bugging BartC (and what prompted my incoherent rambling) >> is that sizeof (S.C) and sizeof (S,C) look so similar. (The context >> being an object S with an array member called C and a declared array >> called C). He's probably built a parse tree where both look exactly the >> same and he's planning to make sizeof "reach into" the operand to see >> what form it takes. >> >> But that's probably the wrong way to handle it. In sizeof (S,C), the >> expression C is adjusted (I prefer your term to converted) to a pointer >> because C is declared to be an array and the context permits (or >> requires if you like) the adjustment. It's permitted because it's a >> expression in its own right -- only expressions get so adjusted. >> >> In sizeof (S.C), the C is just a member name. That C (on it's own) is >> not an expression so it can not have its type adjusted in *any* context. >> The only thing that is an expression is S.C as a whole and that *is* an >> immediate operand to sizeof. The fact that one might represent S.C as >> an expression node in a tree just like (S,C) is simple a convenience. >> The parts of S.C are not expressions -- only the left part and the whole >> thing are expressions. > > It's not just S.C. The operators that can yield array types that would > need pointer adjustment (apart from just the name of an array object), > are "*", ".", "->" and "[]". All expressions with array type need adjustment unless they are an operand of sizeof or &. The trick is to get the right focus (which I definitely messed up in the previous post). The right focus is that the C in S.C (or in P->C) is not an expression. The only expressions in `sizeof S.C` are `S` and `S.C` and `sizeof S.C`. S.C is of array type but does not get adjusted due to it's position as an operand of sizeof. > And those last three can also be reduced > to a single "*" operation. I don't see how . can be (did you mean the last two?). But the argument about S.C does not apply to * expressions. > The method I'm trying is to do the pointer adjustment anyway, whenever > an array type comes up, but to mark that AST node with information > that allows the original array size to recovered, /if/ it ends up as > the immediate operand of sizeof (or of & and so on). > > But that only happens with certain selected kinds of operators, such > as "*", but not comma or ?:. This is according to observed behaviour > rather than wording of the language reference which is none too clear. The gist of it is to convert every array-valued *expression* unless it is the operand of size of or &. The key observation (which is the part I messed up on) is that the C in S.C is not an expression but S.C is. The (direct) operands of the comma operator, ?: and * are all converted because they are not, by definition operands of sizeof or &. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 00:24 +0000 |
| Message-ID | <o8dct5$kl0$1@dont-email.me> |
| In reply to | #104241 |
On 19/02/2017 23:16, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> And those last three can also be reduced
>> to a single "*" operation.
>
> I don't see how . can be (did you mean the last two?).
Given:
struct {int B[10];} S, *R = &S;
int A[10] = {00,10,20,30,40,50,60,70,80,90};
memcpy(&S.B, A, sizeof A);
then conventional ways to access these array elements with . -> and [] are:
printf("A[3] = %d\n", A[3]);
printf("S.B[4] = %d\n", S.B[4]);
printf("R->B[5] = %d\n", R->B[5]);
Reduction to * can be done like this:
printf("A[3] = %d\n", *(&A[0]+3));
printf("S.B[4] = %d\n", *(&S.B[0]+4));
printf("R->B[5] = %d\n", *(&R->B[0]+5));
(And the output is 30,40,50 in both cases.)
(Maybe you thought I meant * only and not the "+" or the [0]? The [0] in
the second lot is to get the right type of pointer, and could be
replaced with a (int*) cast on the term. In machine code, there is no
explicit conversion; the *(S.B[0]+4) can be reduced to a single
instruction with immediate address plus offset)
>> The method I'm trying is to do the pointer adjustment anyway, whenever
>> an array type comes up, but to mark that AST node with information
>> that allows the original array size to recovered, /if/ it ends up as
>> the immediate operand of sizeof (or of & and so on).
>>
>> But that only happens with certain selected kinds of operators, such
>> as "*", but not comma or ?:. This is according to observed behaviour
>> rather than wording of the language reference which is none too clear.
>
> The gist of it is to convert every array-valued *expression* unless it
> is the operand of size of or &.
The problem is that that is difficult to do with a recursive descent
parser. Or at least, inefficient.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-20 00:56 +0000 |
| Message-ID | <87h93padej.fsf@bsb.me.uk> |
| In reply to | #104246 |
BartC <bc@freeuk.com> writes:
> On 19/02/2017 23:16, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> And those last three can also be reduced
>>> to a single "*" operation.
>>
>> I don't see how . can be (did you mean the last two?).
>
> Given:
>
> struct {int B[10];} S, *R = &S;
> int A[10] = {00,10,20,30,40,50,60,70,80,90};
> memcpy(&S.B, A, sizeof A);
>
> then conventional ways to access these array elements with . -> and [] are:
>
> printf("A[3] = %d\n", A[3]);
> printf("S.B[4] = %d\n", S.B[4]);
> printf("R->B[5] = %d\n", R->B[5]);
>
> Reduction to * can be done like this:
>
> printf("A[3] = %d\n", *(&A[0]+3));
*(A + 3) is a simpler * form.
> printf("S.B[4] = %d\n", *(&S.B[0]+4));
Again, *(S.B + 4) is simpler.
> printf("R->B[5] = %d\n", *(&R->B[0]+5));
*(R->B + 5)
> (And the output is 30,40,50 in both cases.)
>
> (Maybe you thought I meant * only and not the "+" or the [0]?
No, I thought you mean that . can be reduced to a single * in a similar
manner to what you can do with []. The "last three" where ., -> and
[]. -> and [], yes, but .?
> The [0]
> in the second lot is to get the right type of pointer, and could be
> replaced with a (int*) cast on the term. In machine code, there is no
> explicit conversion; the *(S.B[0]+4) can be reduced to a single
> instruction with immediate address plus offset)
I think Your AST should use C operators so that you can re-write A[3] as
*(A + 3). If by &A[0] you mean some machine-level operations you need
to make that clear with some new syntax. In C &A[0] means &*(A + 0) so
it does not avoid the things that are bothering you.
>>> The method I'm trying is to do the pointer adjustment anyway, whenever
>>> an array type comes up, but to mark that AST node with information
>>> that allows the original array size to recovered, /if/ it ends up as
>>> the immediate operand of sizeof (or of & and so on).
>>>
>>> But that only happens with certain selected kinds of operators, such
>>> as "*", but not comma or ?:. This is according to observed behaviour
>>> rather than wording of the language reference which is none too clear.
>>
>> The gist of it is to convert every array-valued *expression* unless it
>> is the operand of size of or &.
>
> The problem is that that is difficult to do with a recursive descent
> parser. Or at least, inefficient.
That seems unlikely but I can't prove otherwise without doing it myself
or seeing your code and looking for a simplification.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 01:25 +0000 |
| Message-ID | <o8dgfl$t9d$1@dont-email.me> |
| In reply to | #104249 |
On 20/02/2017 00:56, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 19/02/2017 23:16, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>>> And those last three can also be reduced
>>>> to a single "*" operation.
>>>
>>> I don't see how . can be (did you mean the last two?).
>>
>> Given:
>>
>> struct {int B[10];} S, *R = &S;
>> int A[10] = {00,10,20,30,40,50,60,70,80,90};
>> memcpy(&S.B, A, sizeof A);
>>
>> then conventional ways to access these array elements with . -> and [] are:
>>
>> printf("A[3] = %d\n", A[3]);
>> printf("S.B[4] = %d\n", S.B[4]);
>> printf("R->B[5] = %d\n", R->B[5]);
>>
>> Reduction to * can be done like this:
>>
>> printf("A[3] = %d\n", *(&A[0]+3));
>
> *(A + 3) is a simpler * form.
Yes, that's what I meant! (I have to use explicit address-of internally...)
>
>> printf("S.B[4] = %d\n", *(&S.B[0]+4));
>
> Again, *(S.B + 4) is simpler.
>
>> printf("R->B[5] = %d\n", *(&R->B[0]+5));
>
> *(R->B + 5)
>
>> (And the output is 30,40,50 in both cases.)
>>
>> (Maybe you thought I meant * only and not the "+" or the [0]?
>
> No, I thought you mean that . can be reduced to a single * in a similar
> manner to what you can do with []. The "last three" where ., -> and
> []. -> and [], yes, but .?
I don't see the issue. A[3] becomes *(A+3). S.B[4] becomes *(S.B+4).
What's the difference? The .B is just an extra offset, so it's
(&S+offset) (the new offset is still 4 in my example as the offset of .B
is 0).
Both A and &S are immediate addresses (easier to see when &A is used) to
which a compile-time offset is added. They are doing the same thing.
>> The problem is that that is difficult to do with a recursive descent
>> parser. Or at least, inefficient.
>
> That seems unlikely but I can't prove otherwise without doing it myself
> or seeing your code and looking for a simplification.
I'll try and post a link in a couple of weeks.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 11:14 +0000 |
| Message-ID | <o8eivc$eav$1@dont-email.me> |
| In reply to | #104251 |
On 20/02/2017 01:25, BartC wrote: > On 20/02/2017 00:56, Ben Bacarisse wrote: >> No, I thought you mean that . can be reduced to a single * in a similar >> manner to what you can do with []. The "last three" where ., -> and >> []. -> and [], yes, but .? > > I don't see the issue. A[3] becomes *(A+3). S.B[4] becomes *(S.B+4). > What's the difference? The .B is just an extra offset, so it's > (&S+offset) (the new offset is still 4 in my example as the offset of .B > is 0). The trouble with expressing this stuff as C code is that it has to be just right. The &S needs to be a byte pointer and the new offset is a byte offset (so &S+16 for my example). And the * operator will have the correct type implied (fetching a signed int value from that location). So S.B[4] would be: *(int*)((char*)&S+16) while A[3] would be: *(int*)((char*)&A+12) But hopefully you would have seen past these details. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 27 — ← Prev page 1 [2] 3 4 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web