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 3 of 27 — ← Prev page 1 2 [3] 4 5 … 27 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-20 14:44 +0000 |
| Message-ID | <87bmtwaplh.fsf@bsb.me.uk> |
| In reply to | #104259 |
BartC <bc@freeuk.com> writes: > 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. Of course. But I still can't see what you meant by the original phrase but it seems it had nothing to do with how I interpreted it. Nothing it going to be gained by my going on about what I think you said. It's clear you are talking about something else -- something about which I have no comment to make. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 15:18 +0000 |
| Message-ID | <o8f18g$une$1@dont-email.me> |
| In reply to | #104261 |
On 20/02/2017 14:44, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> 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. > > Of course. But I still can't see what you meant by the original phrase Only that the operators (* . -> []) which I would normally represent by dedicated AST nodes that I call (deref, dot, idot, index) could all in fact be represented by just 'deref' at the top level. Then 'sizeof' only needs to look at 'deref' rather than all four to its special array thing. > but it seems it had nothing to do with how I interpreted it. That's possible too. You seem to think in rather different ways from me... -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-20 15:51 +0000 |
| Message-ID | <8760k4amhx.fsf@bsb.me.uk> |
| In reply to | #104264 |
BartC <bc@freeuk.com> writes: > On 20/02/2017 14:44, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> 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. >> >> Of course. But I still can't see what you meant by the original phrase > > Only that the operators (* . -> []) which I would normally represent > by dedicated AST nodes that I call (deref, dot, idot, index) could all > in fact be represented by just 'deref' at the top level. Then 'sizeof' > only needs to look at 'deref' rather than all four to its special > array thing. I thought that was what you meant but you did not give a simple example of . being re-written. In fact, in the first, pass all your . examples included the . operator. If it helps, and you can get the details right, then obviously there is nothing wrong with it. But I am a little sceptical that re-writing S.C /* C is an array of 10 ints */ as *( int (*)[10] )((char *)&S + offsetof(S, C)) really helps. For one thing, you will run into trouble where the expression on the LHS of the dot is not an lvalue. How would you re-write f().C where F returns a struct of the same type as the name S? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 16:16 +0000 |
| Message-ID | <o8f4kk$bpn$1@dont-email.me> |
| In reply to | #104267 |
On 20/02/2017 15:51, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Only that the operators (* . -> []) which I would normally represent >> by dedicated AST nodes that I call (deref, dot, idot, index) could all >> in fact be represented by just 'deref' at the top level. > I thought that was what you meant but you did not give a simple example > of . being re-written. In fact, in the first, pass all your . examples > included the . operator. Oh yeah; I didn't notice! But I know is that from experience, these ops can always reduce down to low-level address, offset and pointer [deref] operations. > If it helps, and you can get the details right, then obviously there is > nothing wrong with it. But I am a little sceptical that re-writing > > S.C /* C is an array of 10 ints */ > > as > > *( int (*)[10] )((char *)&S + offsetof(S, C)) > > really helps. For one thing, you will run into trouble where the > expression on the LHS of the dot is not an lvalue. How would you > re-write > > f().C > > where F returns a struct of the same type as the name S? I've never implemented a struct return type in the way that C does it. But I think it involves using a local temporary struct value that the function can be told to write the contents to. Then that temp can be treated the same way as S. (But this starts to encroach on code generation; I will need to do it first before I can answer that fully.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-23 12:23 +0000 |
| Message-ID | <o8mk8d$516$1@z-news.wcss.wroc.pl> |
| In reply to | #104246 |
BartC <bc@freeuk.com> wrote:
> On 19/02/2017 23:16, Ben Bacarisse wrote:
> >
> > 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.
With sizeof (and probably also &) recursive descent parser
will know that is handling sizeof before parsing its argument.
So just pass appropriate flag to routine which parses argument.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-19 15:49 -0800 |
| Message-ID | <4a1d176e-0c60-422e-9eb0-04574b2f32ef@googlegroups.com> |
| In reply to | #104236 |
On Sunday, February 19, 2017 at 4:23:24 PM UTC-6, Bart wrote:
> 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).
Is your logic to do the decay when something is observed as not being used
in a situation where decay should be prevented, or when it's observed as
being used in a situation where decay is required? I'd suggest that latter
approach.
I'd also suggest, especially if your goal is to have a language which is
compatible with common C code but doesn't try to follow all the weird
wrinkles, that [] be viewed as operators that operate directly on array
types, rather than as causing an array-to-pointer decay, a pointer indexing
operation, and a pointer dereference. Among other things, that would make
clear that given:
register uint8_t arr1[4];
code should be able to access elements of arr1 using [] without requiring
that the array have an address [the Standard requires implementations to
accept code which attempts to access members of register-qualified arrays,
but imposes no requirements upon what the code does; defining it as behaving
like elements in a collection that might not have an address would seem more
sensible].
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 00:55 +0000 |
| Message-ID | <o8demi$or5$1@dont-email.me> |
| In reply to | #104243 |
On 19/02/2017 23:49, supercat@casperkitty.com wrote: > On Sunday, February 19, 2017 at 4:23:24 PM UTC-6, Bart wrote: >> 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). > > Is your logic to do the decay when something is observed as not being used > in a situation where decay should be prevented, or when it's observed as > being used in a situation where decay is required? I'd suggest that latter > approach. To decay every time an array type results. And to reverse that when it turns out sizeof or & operates on it. (I just to get something working so I can see how fast it might be! However, sizeof is already slowing it down more than I'd expected.) > I'd also suggest, especially if your goal is to have a language which is > compatible with common C code but doesn't try to follow all the weird > wrinkles, that [] be viewed as operators that operate directly on array > types, rather than as causing an array-to-pointer decay, a pointer indexing > operation, and a pointer dereference. For the minute, a[i] reduces to pointer addition and deref operations (eg. (deref (addptr (addrof a) i))). However it makes code generation simpler if it stays as a higher level, dedicated 'index' operation (eg. (index a i)). Easier to reduce down to what will be a single address mode a lot of the time, and probably faster. > Among other things, that would make > clear that given: > > register uint8_t arr1[4]; > > code should be able to access elements of arr1 using [] without requiring > that the array have an address [the Standard requires implementations to > accept code which attempts to access members of register-qualified arrays, I'd find that tricky to do anyway. But it's unlikely to come up in the unsophisticated code generation I would use. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-20 10:05 +0100 |
| Message-ID | <o8ebd6$mis$1@dont-email.me> |
| In reply to | #104243 |
On 20/02/17 00:49, supercat@casperkitty.com wrote: > On Sunday, February 19, 2017 at 4:23:24 PM UTC-6, Bart wrote: >> 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). > > Is your logic to do the decay when something is observed as not being used > in a situation where decay should be prevented, or when it's observed as > being used in a situation where decay is required? I'd suggest that latter > approach. > > I'd also suggest, especially if your goal is to have a language which is > compatible with common C code but doesn't try to follow all the weird > wrinkles, that [] be viewed as operators that operate directly on array > types, rather than as causing an array-to-pointer decay, a pointer indexing > operation, and a pointer dereference. Among other things, that would make > clear that given: > > register uint8_t arr1[4]; > > code should be able to access elements of arr1 using [] without requiring > that the array have an address [the Standard requires implementations to > accept code which attempts to access members of register-qualified arrays, > but imposes no requirements upon what the code does; defining it as behaving > like elements in a collection that might not have an address would seem more > sensible]. > No, using this array (other than sizeof or _Alignof) is not allowed. See footnote 121 in ยง6.7.1 where "register" is defined. Anyway, the "register" keyword is not useful with modern tools - almost any compiler will do a perfectly good (better than the programmer in most cases) job of determining what should be kept in registers. A local array will be kept in registers if the cpu has enough registers and the code is more efficient that way - there is no need to declare it as "register". C++ has already deprecated the keyword "register" as it is virtually useless in practice.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 07:08 -0800 |
| Message-ID | <e481bb65-b8cd-4020-8925-3e7363ebf373@googlegroups.com> |
| In reply to | #104257 |
On Monday, February 20, 2017 at 3:05:36 AM UTC-6, David Brown wrote:
> On 20/02/17 00:49, supercat wrote:
> > I'd also suggest, especially if your goal is to have a language which is
> > compatible with common C code but doesn't try to follow all the weird
> > wrinkles, that [] be viewed as operators that operate directly on array
> > types, rather than as causing an array-to-pointer decay, a pointer indexing
> > operation, and a pointer dereference. Among other things, that would make
> > clear that given:
> >
> > register uint8_t arr1[4];
> >
> > code should be able to access elements of arr1 using [] without requiring
> > that the array have an address [the Standard requires implementations to
> > accept code which attempts to access members of register-qualified arrays,
> > but imposes no requirements upon what the code does; defining it as behaving
> > like elements in a collection that might not have an address would seem more
> > sensible].
The example given is one where a conforming program may use the [] operators
on an object without an address (though such a program could only be strictly
conforming if the code in question were never actually executed). A more
useful example, though I think the Standard would unfortunately regard it as
a constraint violation despite its usefulness, would be something like:
struct thing {
unsigned foo:4[16];
};
to yield something that could be used as an array of 4-bit values which a
compiler could handle using bit shifts on a 64-bit value, or a combination
of bit-shifting and masking on two 32-bit values, four 16-bit values,
eight 8-bit values, or any combination of the above that it found convenient.
Some processors include features that would allow the above to be handled
quite efficiently, and if a compiler does include such features it would
probably be easier for a compiler to expose them efficiently using something
like the above than by trying to have an optimizer try to convert user code
which is written with a combination of masks and shifts into a more efficient
combination of indexed bit-field manipulation instructions.
The latter feature would be far more useful than "register", but would
require a language extension. The "register" construct wouldn't have a whole
lot of uses, but if a structure field of a small array type had a register
qualifier, it might affect the calling convention used with the structure
(if a structure which contains a "uint8_t[4]" and nothing else will not
usually have code take the address of that array, it may be most efficiently
passed and kept in a 32-bit register, but if code will need to take the
address of the array, it may be more efficient to keep the array in memory
and pass around its address). A compiler that sees a structure definition
would have no way of knowing which usage would be more common, but adding a
"register" qualifier to the array could provide a useful hint, provided that
definitions of the structure in all compilation units either have the
qualifier or lack it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-20 16:23 +0100 |
| Message-ID | <o8f1io$vtd$1@dont-email.me> |
| In reply to | #104263 |
On 20/02/17 16:08, supercat@casperkitty.com wrote:
> On Monday, February 20, 2017 at 3:05:36 AM UTC-6, David Brown wrote:
>> On 20/02/17 00:49, supercat wrote:
>>> I'd also suggest, especially if your goal is to have a language which is
>>> compatible with common C code but doesn't try to follow all the weird
>>> wrinkles, that [] be viewed as operators that operate directly on array
>>> types, rather than as causing an array-to-pointer decay, a pointer indexing
>>> operation, and a pointer dereference. Among other things, that would make
>>> clear that given:
>>>
>>> register uint8_t arr1[4];
>>>
>>> code should be able to access elements of arr1 using [] without requiring
>>> that the array have an address [the Standard requires implementations to
>>> accept code which attempts to access members of register-qualified arrays,
>>> but imposes no requirements upon what the code does; defining it as behaving
>>> like elements in a collection that might not have an address would seem more
>>> sensible].
>
> The example given is one where a conforming program may use the [] operators
> on an object without an address (though such a program could only be strictly
> conforming if the code in question were never actually executed).
I don't think there is any way in standard C to apply [] to a register
qualified array. You cannot even write "sizeof arr1[1]".
(Implementations, such as gcc, may be more lenient.)
> A more
> useful example, though I think the Standard would unfortunately regard it as
> a constraint violation despite its usefulness, would be something like:
>
> struct thing {
> unsigned foo:4[16];
> };
>
> to yield something that could be used as an array of 4-bit values which a
> compiler could handle using bit shifts on a 64-bit value, or a combination
> of bit-shifting and masking on two 32-bit values, four 16-bit values,
> eight 8-bit values, or any combination of the above that it found convenient.
I can see how this might be useful, but it is not C as we have it today.
> Some processors include features that would allow the above to be handled
> quite efficiently, and if a compiler does include such features it would
> probably be easier for a compiler to expose them efficiently using something
> like the above than by trying to have an optimizer try to convert user code
> which is written with a combination of masks and shifts into a more efficient
> combination of indexed bit-field manipulation instructions.
>
> The latter feature would be far more useful than "register", but would
> require a language extension. The "register" construct wouldn't have a whole
> lot of uses, but if a structure field of a small array type had a register
> qualifier, it might affect the calling convention used with the structure
> (if a structure which contains a "uint8_t[4]" and nothing else will not
> usually have code take the address of that array, it may be most efficiently
> passed and kept in a 32-bit register, but if code will need to take the
> address of the array, it may be more efficient to keep the array in memory
> and pass around its address). A compiler that sees a structure definition
> would have no way of knowing which usage would be more common, but adding a
> "register" qualifier to the array could provide a useful hint, provided that
> definitions of the structure in all compilation units either have the
> qualifier or lack it.
>
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-20 16:03 +0000 |
| Message-ID | <o8f3s6$8qk$1@dont-email.me> |
| In reply to | #104263 |
On 20/02/2017 15:08, supercat@casperkitty.com wrote:
> On Monday, February 20, 2017 at 3:05:36 AM UTC-6, David Brown wrote:
> A more
> useful example, though I think the Standard would unfortunately regard it as
> a constraint violation despite its usefulness, would be something like:
>
> struct thing {
> unsigned foo:4[16];
> };
>
> to yield something that could be used as an array of 4-bit values which a
> compiler could handle using bit shifts on a 64-bit value, or a combination
> of bit-shifting and masking on two 32-bit values, four 16-bit values,
> eight 8-bit values, or any combination of the above that it found convenient.
Adding general bit and bitfield types into the type system would be
quite a heavy feature I think, and would require bit and bitfield pointers.
Another way, if restricted to within 64-bit values, would be to do it
with special operators. I used, for example (in a non-C language):
A.[i]
to access the i'th bit, and A.[i..j] to extract a bitfield. In yet
another language, I use A.byte[i] to access the i'th byte of A, whatever
A happened to be.
Some of these worked as lvalues too. It might just be possible I think
for such operators to be lvalues for assignments without introducing
general-purpose bit pointers.
But isn't the C way to do this sort of thing with macros? It wouldn't be
as nice, but then you don't need to do anything to the language.
> The latter feature would be far more useful than "register", but would
> require a language extension. The "register" construct wouldn't have a whole
> lot of uses, but if a structure field of a small array type had a register
> qualifier, it might affect the calling convention used with the structure
> (if a structure which contains a "uint8_t[4]" and nothing else will not
> usually have code take the address of that array, it may be most efficiently
> passed and kept in a 32-bit register, but if code will need to take the
> address of the array, it may be more efficient to keep the array in memory
> and pass around its address). A compiler that sees a structure definition
> would have no way of knowing which usage would be more common, but adding a
> "register" qualifier to the array could provide a useful hint, provided that
> definitions of the structure in all compilation units either have the
> qualifier or lack it.
I can't see why an implementation can't decide to keep a small 32- or
64-bit array in a register anyway. It doesn't need intervention within
the code.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 08:45 -0800 |
| Message-ID | <9e683fb3-c692-4777-8e58-6ab23eee68ff@googlegroups.com> |
| In reply to | #104268 |
On Monday, February 20, 2017 at 10:03:09 AM UTC-6, Bart wrote:
> Adding general bit and bitfield types into the type system would be
> quite a heavy feature I think, and would require bit and bitfield pointers.
It would be a heavy feature to *mandate*. Some processors, however, do have
instructions which accept an address in one register, a sub-word index in
another, and can easily load or store a value from a portion of a word, and
it would seem useful to have a standard syntax which, if accepted, would have
a consistent meaning. Even if all implementations supported it, there would
likely be some where it was used often and some where it never got used, so
allowing implementers to support it or not based upon customer requirements
would seem better than mandating support everywhere.
On the other hand, allowing implementations to either support it or not at
their leisure would impose almost no cost on those implementers that chose
not to support it. All they would have to do is read enough about the
feature to decide they don't want to support it, and refrain from defining
macros with certain names that would indicate that support was available.
I see no reason such a construct would require bit- or bitfield pointers.
Code which wants to access an item of such an array would need a pointer to
the enclosing structure as well as the index of the array. It would be
necessary to regard foo[i] as having a meaning which isn't always the same
as *(foo+i), but that's not really much different from saying that, given
struct foo {int x,y; } *fooPtr;
fooPtr->y has a meaning which isn't exactly equivalent to
*(int*)(offsetof(struct foo, y) + (char*)fooPtr)
even though how the latter form is essentially how foo->y was defined in
C74.
> But isn't the C way to do this sort of thing with macros? It wouldn't be
> as nice, but then you don't need to do anything to the language.
A problem with macros is that it's much harder for a compiler to figure
out that the purpose of a mass of shifts and bit masks is to store a
half-byte value into an indexed collection of them, and replace that mass
with a bitfield-store instruction, than it would be for the compiler to
take a syntax like ptr->member[i], recognize that as applying the []
operator to an array of 4-bit fields, and generate a bitfield-store
instruction from that.
> > The latter feature would be far more useful than "register", but would
> > require a language extension. The "register" construct wouldn't have a whole
> > lot of uses, but if a structure field of a small array type had a register
> > qualifier, it might affect the calling convention used with the structure
> > (if a structure which contains a "uint8_t[4]" and nothing else will not
> > usually have code take the address of that array, it may be most efficiently
> > passed and kept in a 32-bit register, but if code will need to take the
> > address of the array, it may be more efficient to keep the array in memory
> > and pass around its address). A compiler that sees a structure definition
> > would have no way of knowing which usage would be more common, but adding a
> > "register" qualifier to the array could provide a useful hint, provided that
> > definitions of the structure in all compilation units either have the
> > qualifier or lack it.
>
> I can't see why an implementation can't decide to keep a small 32- or
> 64-bit array in a register anyway. It doesn't need intervention within
> the code.
Depending upon how a structure is used, it may be more efficient to have
code pass around an address to something that simply sits in memory, or it
may be more efficient to have a caller load the object from memory into
a register and require that the called function write it to memory so it
can create a pointer to it. More notably, a "register" qualifier could
indicate that an array within a structure would not be accessed via means
other than through the structure-type lvalue. Given, e.g.
struct foo {int x[4]; };
a compiler which had a "struct foo*" and an "int*", both of unknown
provenance, would have to assume that any access to the "int*" might be
an access to the array within the struct foo. A register qualifier
could entitle a compiler to ignore such aliasing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-20 09:17 -0800 |
| Message-ID | <lnh93on5n4.fsf@kst-u.example.com> |
| In reply to | #104272 |
supercat@casperkitty.com writes:
> On Monday, February 20, 2017 at 10:03:09 AM UTC-6, Bart wrote:
>> Adding general bit and bitfield types into the type system would be
>> quite a heavy feature I think, and would require bit and bitfield pointers.
>
> It would be a heavy feature to *mandate*. Some processors, however, do have
> instructions which accept an address in one register, a sub-word index in
> another, and can easily load or store a value from a portion of a word, and
> it would seem useful to have a standard syntax which, if accepted, would have
> a consistent meaning. Even if all implementations supported it, there would
> likely be some where it was used often and some where it never got used, so
> allowing implementers to support it or not based upon customer requirements
> would seem better than mandating support everywhere.
Great. That's exactly the current situation. Implementations are
free to support general bit and bitfield types *as an extension*.
They can even collaborate to settle on consistent syntax and
semantics, and perhaps document it as a secondary standard.
There's no particular need to change the C stndaard itself.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 12:25 -0800 |
| Message-ID | <726ddfc8-83af-47db-8a18-08d921816e82@googlegroups.com> |
| In reply to | #104274 |
On Monday, February 20, 2017 at 11:17:33 AM UTC-6, Keith Thompson wrote: > supercat writes: > > It would be a heavy feature to *mandate*. Some processors, however, do have > > instructions which accept an address in one register, a sub-word index in > > another, and can easily load or store a value from a portion of a word, and > > it would seem useful to have a standard syntax which, if accepted, would have > > a consistent meaning. Even if all implementations supported it, there would > > likely be some where it was used often and some where it never got used, so > > allowing implementers to support it or not based upon customer requirements > > would seem better than mandating support everywhere. > > Great. That's exactly the current situation. Implementations are > free to support general bit and bitfield types *as an extension*. > They can even collaborate to settle on consistent syntax and > semantics, and perhaps document it as a secondary standard. > There's no particular need to change the C stndaard itself. The Standard would regard any program that uses such a feature as "non-conforming" and would mandate that any conforming implementation output a diagnostic upon receipt of such a construct, even if the implementation supported the feature in question. Further, if the Standard defines a behavior for an optional construct, that would offer some assurance that neither the Standard nor other implementations will define a construct which is incompatible with it, which could help overcome chicken-and-egg friction. How many features in C11 offer a systems programmer any useful semantics that weren't available in some C implementations even prior to the publication of the C89 Standard? There have been some things like "restrict" which allow programmers to invite compilers to make useful optimizations, and variadic macros and generics could be useful, and 64-bit integer types are nice on hardware that supports them but making those mandatory rather than optional (and of course strongly recommended) makes the language less suitable for use on smaller platforms. If the authors of the Standard were more open to recognizing optional features that would be useful on some platforms but not others, that would facilitate useful innovation. As it is, the language really seems quite stagnant.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-20 12:29 -0800 |
| Message-ID | <ln4lzomwrg.fsf@kst-u.example.com> |
| In reply to | #104287 |
supercat@casperkitty.com writes:
> On Monday, February 20, 2017 at 11:17:33 AM UTC-6, Keith Thompson wrote:
[...]
>> Great. That's exactly the current situation. Implementations are
>> free to support general bit and bitfield types *as an extension*.
>> They can even collaborate to settle on consistent syntax and
>> semantics, and perhaps document it as a secondary standard.
>> There's no particular need to change the C stndaard itself.
>
> The Standard would regard any program that uses such a feature as
> "non-conforming"
No, it would fit within the Standard's (very weak) definition of the
term "conforming program".
> and would mandate that any conforming implementation
> output a diagnostic upon receipt of such a construct, even if the
> implementation supported the feature in question.
Yes. So use the compiler in non-conforming mode if you want to use the
extension.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 13:20 -0800 |
| Message-ID | <3bee4191-6834-4b99-bf92-d8ca5b8b34e2@googlegroups.com> |
| In reply to | #104288 |
On Monday, February 20, 2017 at 2:28:05 PM UTC-6, Keith Thompson wrote: > supercat writes: > > The Standard would regard any program that uses such a feature as > > "non-conforming" > > No, it would fit within the Standard's (very weak) definition of the > term "conforming program". I thought that conforming programs were required to be well formed if they don't contain any #pragma directives or reserved identifiers for which the Standard defines no meaning. Otherwise, any source file could be turned into a conforming program with the aid of an "implementation" which checks whether it matches some hard-coded reference file, outputs a hard-coded executable if so, and otherwise feeds the program to a "real" implementation. > > and would mandate that any conforming implementation > > output a diagnostic upon receipt of such a construct, even if the > > implementation supported the feature in question. > > Yes. So use the compiler in non-conforming mode if you want to use the > extension. That would be possible, but for whatever reason compiler writers have been extremely loath to extend the language via any means other than by defining reserved identifiers--among other things because they have no way of knowing whether any syntax they decide to use might be given an incompatible meaning by a future standard. Saying "a compiler may either accept X and give it a certain meaning, or reject X" would suggest that future standards would be unlikely to give X a contrary meaning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-20 13:50 -0800 |
| Message-ID | <lnzihgleff.fsf@kst-u.example.com> |
| In reply to | #104292 |
supercat@casperkitty.com writes:
> On Monday, February 20, 2017 at 2:28:05 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > The Standard would regard any program that uses such a feature as
>> > "non-conforming"
>>
>> No, it would fit within the Standard's (very weak) definition of the
>> term "conforming program".
>
> I thought that conforming programs were required to be well formed if they
> don't contain any #pragma directives or reserved identifiers for which the
> Standard defines no meaning.
Why did you think that, and what exactly does "well formed" mean? (The
C++ standard uses the term "well-formed"; the C standard does not.)
By definition (N1570 4p7):
A *conforming program* is one that is acceptable to a conforming
implementation.
> Otherwise, any source file could be turned
> into a conforming program with the aid of an "implementation" which checks
> whether it matches some hard-coded reference file, outputs a hard-coded
> executable if so, and otherwise feeds the program to a "real" implementation.
Yes, that is what the standard's definition of "conforming program"
implies. It's not a particularly useful concept as far as I can tell.
I think I've read that it was added to the standard (it appears in C90)
for political reasons.
There's some discussion in the ANSI C Rationale,
https://www.lysator.liu.se/c/rat/a.html#1-7 .
>> > and would mandate that any conforming implementation
>> > output a diagnostic upon receipt of such a construct, even if the
>> > implementation supported the feature in question.
>>
>> Yes. So use the compiler in non-conforming mode if you want to use the
>> extension.
>
> That would be possible, but for whatever reason compiler writers have been
> extremely loath to extend the language via any means other than by defining
> reserved identifiers--among other things because they have no way of knowing
> whether any syntax they decide to use might be given an incompatible meaning
> by a future standard. Saying "a compiler may either accept X and give it a
> certain meaning, or reject X" would suggest that future standards would be
> unlikely to give X a contrary meaning.
Most of the extensions provided by gcc are not defined in that way. I'm
less familiar with extensions provided by other compilers.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 14:08 -0800 |
| Message-ID | <68dc7263-0d48-432b-bc08-a6536fda6382@googlegroups.com> |
| In reply to | #104294 |
On Monday, February 20, 2017 at 3:50:23 PM UTC-6, Keith Thompson wrote:
> Most of the extensions provided by gcc are not defined in that way. I'm
> less familiar with extensions provided by other compilers.
The gcc extensions I'm familiar with that don't use reserved identifiers go
back a long time. I'm not positive, but I think they predate the C89 Standard
and the authors of gcc had hoped that the Standard would regard programs using
such extensions as being well formed and not requiring a diagnostic.
I'd be curious to know of gcc extensions that don't use reserved identifiers
and don't predate C89. I'm pretty certain that zero-size arrays (offering
the semantics of what C99 would eventually support via Flexible Array
Members, but with slightly different syntax) were present from the early days,
as was the ({ }) syntax for statement expressions, // syntax for comments,
and the ability to use anonymous aggregate members.
What syntactic innovations came later?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-20 15:16 -0800 |
| Message-ID | <lnvas4lah6.fsf@kst-u.example.com> |
| In reply to | #104297 |
supercat@casperkitty.com writes:
> On Monday, February 20, 2017 at 3:50:23 PM UTC-6, Keith Thompson wrote:
>> Most of the extensions provided by gcc are not defined in that way. I'm
>> less familiar with extensions provided by other compilers.
>
> The gcc extensions I'm familiar with that don't use reserved
> identifiers go back a long time. I'm not positive, but I think they
> predate the C89 Standard and the authors of gcc had hoped that the
> Standard would regard programs using such extensions as being well
> formed and not requiring a diagnostic.
>
> I'd be curious to know of gcc extensions that don't use reserved
> identifiers and don't predate C89. I'm pretty certain that zero-size
> arrays (offering the semantics of what C99 would eventually support
> via Flexible Array Members, but with slightly different syntax) were
> present from the early days, as was the ({ }) syntax for statement
> expressions, // syntax for comments, and the ability to use anonymous
> aggregate members.
>
> What syntactic innovations came later?
I don't know. The history of gcc is publicly available.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 16:19 -0800 |
| Message-ID | <e9cf668e-dc05-4850-ad09-43f0b1e785da@googlegroups.com> |
| In reply to | #104300 |
On Monday, February 20, 2017 at 5:15:14 PM UTC-6, Keith Thompson wrote:
> I don't know. The history of gcc is publicly available.
I've not found information about gcc versions prior to about 1997. It seems
that development split because one group was too conservative, while another
wanted to add things like "New alias analysis support from John F. Carr". I
would be genuinely interested in knowing whether that fork represents the
first time that anyone involved with gcc gave serious thought to the notion
that a quality compiler given something like:
void force_float_negative(float *f1)
{
*(unsigned long*)f1 |= 0x80000000;
}
should optimize on the presumption that such a function won't actually be
used to access something of the passed-in pointer type. I can't find any
substantive information about previous versions or the documentation
therefor, however. I remember having noticed most of the aforementioned
features when looking at the documentation for gcc in the early 1990s when
it was being used to write code for a CPU compatible with the Motorola
68000.
[toc] | [prev] | [next] | [standalone]
Page 3 of 27 — ← Prev page 1 2 [3] 4 5 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web