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 10 of 27 — ← Prev page 1 … 8 9 [10] 11 12 … 27 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 14:02 -0800 |
| Message-ID | <585736e4-71bd-4b44-b293-551addad6562@googlegroups.com> |
| In reply to | #105301 |
On Wednesday, March 1, 2017 at 2:01:02 PM UTC-6, David Brown wrote:
> On 01/03/17 19:49, supercat wrote:
> > Given:
> >
> > union u { int x; float y; } *up;
> >
> > if there is nothing to distinguish between:
> >
> > int foo(float f) { up->y=f; return up->x; }
> >
> > and
> >
> > int test(int *x, float *y, float f) { *y = f; return *x; }
> > int foo(float f) { test(&u->x, &u->y, f); }
> >
> > that would suggest that the behavior of the latter would be defined in terms
> > of the behavior of the first. Is there anything in C89 which would
> > distinguish the behaviors of the two forms? I recall a defect report
> > which suggested that since the first yielded Implementation-Defined behavior
> > the second should be regarded as yielding UB, but I saw nothing in the text
> > of the Standard which would come close to justifying such logic.
>
> In "test", the compiler knows that y and x cannot alias. It is free to
> implement it as though it were written:
>
> int test(int * x, float * y, float f) {
> int t = *x;
> *y = f;
> return t;
What in the C89 would entitle a compiler which specified a particular
behavior when writing one union member and reading another, **and did not
specify that the behavior might vary when objects are accessed via
pointers**, to have a write of one member, accomplished via pointer, and
a read of another, also accomplished via pointer, behave in a fashion that
is not consistent with the specified behavior?
If a C89 implementation wanted to specify that reads and writes performed
by directly accessing a member of a union type or portion thereof would
cause the binary representation of one type to be interpreted as the other,
and in all other cases writing as one type and reading anything that wasn't
part of a CIS would yield Unspecified value, it would have been free to
do that.
What basis is there for saying that a C89 implementation may treat reads
and writes through pointers differently from reads and writes performed
directly through union members without having to specify that it might
do so?
> This is a perfectly allowed transformation under C89, as far as I
> interpret the standard.
Whether it is allowed or not would depend upon what the implementation's
documentation specifies about the corresponding behavior of union objects.
> I believe you are making the argument:
>
> 1. Compilers in the days of C89 were not smart enough to do type-based
> alias optimisations.
They did some such optimizations, most commonly by observing when there was
a read of a value that had been accessed previously and its value was still
in a register. On platforms where "localized" type punning could be useful,
flushing cached values when pointer casts were performed was an easy way to
allow it while allowing useful optimizations in the vastly more common cases
where values could be reused without any intervening pointer conversions.
> 2. Programmers in the days of C89 wrote code that accessed data through
> pointers of different types - it was safe to do so because, compilers
> generated the code they expected. Using standards-blessed methods, such
> as memcpy, was much less efficient (due to limited compiler
> optimisations), and using unions was implementation-dependent (and less
> efficient with those compilers).
Using memcpy forces compilers to make aliasing assumptions that are far
more pessimistic than assuming that casts imply likely localized aliasing.
Further, the way C99 defines memcpy, it can only serve the purpose you
describe in cases where the destination has a declared type. C99 has no
efficient equivalent for use in cases where the destination needs to be
readable as arbitrary type.
> 3. Therefore, C89 allowed code that is broken by today's optimising
> compilers and/or the C99 standard.
C89 allowed such code *except on implementations which specified that a
non-CIS read of a union member other than the last one written might yield
behavior contrary to the code's requirements*.
> > The only C89 implementations on which it would fail would be those which
> > *specify* that reading a union member other than the last one written may
> > have effects beyond yielding a meaningless value. How many embedded C89
> > implementations specify such a thing?
>
> C89 says that this sort of use of unions is implementation-defined,
> while C99 gives a clear (and obvious) definition. How is the C89
> specification better here?
C99 and C11 fail to specify *any* consistent behavioral model for pointers
to union members. I'd say "Implementation Defined" is better than that.
> > Nothing suggests that writing a pointer of one type and reading a pointer
> > of another is any different from writing a union member of the first type
> > and reading a member of the second, except in the cases where the former
> > would be implementation-defined behavior and the latter would yield a
> > specific behavior mandated by the Standard (e.g. when using pointers of
> > character type).
>
> Nothing suggests that it is the same - I cannot imagine why you think
> this. Type-punning through unions is implementation defined in C89, and
> explicitly allowed in C99 - C99 gives you /more/. Accessing a value
> through different pointer types (except for char pointers) is clearly
> undefined in both C89 and C99 - nowhere in either standard is there any
> suggestion that it is related to unions.
In cases where accessing unionPtr->member would yield Implementation-Defined
behavior, an implementation would be free specify behavior which depends
upon the form of expression used for the access, among other things.
If an implementation does not document any cases where the result of
accessing unionPtr->member would depend upon the form of expression used
for the access, in what other cases would taking the address of an lvalue
and dereferencing the received pointer not yield semantics matching those
of using the lvalue directly?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-01 12:28 -0800 |
| Message-ID | <lnwpc8bv32.fsf@kst-u.example.com> |
| In reply to | #105298 |
supercat@casperkitty.com writes:
> On Wednesday, March 1, 2017 at 12:03:05 PM UTC-6, David Brown wrote:
>> On 01/03/17 17:37, supercat wrote:
>> Exactly /which/ behaviours might that be? Be short and to the point - I
>> don't want to read a long essay. And I expect you to be able to show in
>> the C89 standard a reference to where the behaviour is defined, and in
>> the C99 standard a reference to showing that the behaviour is now undefined.
>
> The ability to write storage as one type and read it as any type which has
> no trap representations, with no side-effect beyond yielding a possibly-
> meaningless value.
[77 lines deleted]
I note the lack of any references to the C89/C90 or C99 standard.
Such a reference would include a section number, probably a paragraph
number, and preferably a copy-and-paste of the relevant text from
the standard.
--
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-03-01 12:17 -0800 |
| Message-ID | <4eee6962-3e8f-47e0-a794-42c0fe29c86e@googlegroups.com> |
| In reply to | #105291 |
On Wednesday, March 1, 2017 at 12:03:05 PM UTC-6, David Brown wrote: > > I think you mean "gcc -fno-strict-aliasing", which forces the compiler to > > support C89 semantics which it otherwise would not. The language processed > > without that flag is not suitable for embedded use. > > "-fno-strict-alias" tells the compiler not to use type-based alias > analysis. It has nothing to do with C89 semantics - C89 did not allow > /any/ more aliased access than C99 does. In fact, it allows less. C99 > allows allocated data to get a new effective type in a slightly more > flexible manner than C89 - as far as I can tell, C99 allows you to take > the return of malloc() and assign it to a pointer. ... Under C89, compilers gained permission for aliasing analysis from two sources: the pointer-type rules said that compilers may assume there will be no aliasing between pointers and objects with declared types that are incompatible with them; the union rules allowed implementations to specify how compilers treated aliasing through objects which--as far as the compiler could tell--might possibly be members of the same union. Note that if the Standard specified the effect of pointer-based type punning but said nothing about union-based punning, behavior would be guaranteed only for union objects whose address was taken. Describing the behavior for unions, by contrast, would essentially imply matching behavior for pointer-based punning unless an implementation were to go out of its way to identify cases where it wouldn't have to. Otherwise, the only way an implementation could uphold the guarantees required when accessing union members through pointers would be to uphold those same guarantees to things that might be union members. BTW, I should mention that the authors of gcc have very emphatically stated that the behaviors of existing versions of gcc should not be taken as implying anything about the behavior of future versions with regard to any behaviors which are neither mandated by the Standard nor guaranteed by gcc's documentation, and gcc's documentation doesn't actually specify that -fno-strict-aliasing will cause code whose behavior would be defined in the absence of the aliasing rules to be processed in a fashion consistent with that.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-07 14:53 -0800 |
| Message-ID | <66c5dc8e-7878-4b46-afec-b581d7ba372f@googlegroups.com> |
| In reply to | #105291 |
On Wednesday, March 1, 2017 at 12:03:05 PM UTC-6, David Brown wrote:
> This would all be nicer if C had a way of saying that a pointer is to an
> "allocated object" with "no declared type" other than through the
> <stdlib.h> functions.
>
> But why do you think C89 is any different here?
In C89, the effect of writing one member of a union and reading another is
Implementation Defined, except in cases defined by the Standard (e.g. those
involving Common Initial Sequence). If T and U are non-array types, then
given:
union UT { T t; U u; } *ut;
C89 says that:
(T*)ut and &(ut->t) are equivalent.
(U*)ut and &(ut->u) are equivalent
(UT*)&(ut->t), (UT*)(&ut->u), and ut are all equivalent
Plug those together, and if code receives a pointer from outside code to
what could possibly be a union object compatible with UT, then the behavior
of casting the pointer to T* and writing a T, then casting to a U* and
reading a U, would be equivalent to writing a union member as type T and
reading a union member of type U, and thus Implementation-Defined.
The C89 Standard would give implementations great latitude to say that the
read will yield a bitwise translation in some situations, an Unspecified
Value in some others, and nasal demons in the rest, but an implementation
that does anything weird with aliasing involving storage received from
outside code *must document such behavior*. If an implementation says that
access through a union will perform bitwise reinterpretation, and does not
specify any other required conditions to guarantee such behavior, then type
punning involving pointers received from outside code would have defined
behavior on such an implementation.
IIRC, a defect report said that because aliasing through unions is
Implementation-Defined, that made aliasing through pointers Undefined,
but offered no particular justification for doing so; the intention may
have been to allow implementations more freedom for aliasing, but all
that such an implementation would have to do to exercise such freedom is
specify the conditions under which various behavioral guarantees would
or would not apply. I don't see any justification, either in the Standard
or from a practical standpoint, for saying that implementations should be
allowed to interpret pointer-based aliasing in arbitrary fashion *without
having to document situations where they may do so*.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-01 09:10 -0800 |
| Message-ID | <lnh93cdisv.fsf@kst-u.example.com> |
| In reply to | #105250 |
supercat@casperkitty.com writes:
[...]
> My approach would not require a compiler to track what kinds of conversions
> have been done with objects, but rather regard conversions as a type of
> sequenced *action* which will not generate any code, but must be carried
> through the optimizer as an action which doesn't generate any code, somewhat
> like an empty asm directive.
If you're talking about conversions in general, that's clearly absurd.
For example, an int-to-double conversion must generate some code (unless
the result can be determined at compile time).
If you're talking only about pointer conversions, apparently you're
proposing that the language should require that all pointer types have
the same representation. Is that what you're proposing?
--
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-03-01 09:51 -0800 |
| Message-ID | <2d46f0b1-2a02-490b-bdc4-6d138272e6ca@googlegroups.com> |
| In reply to | #105282 |
On Wednesday, March 1, 2017 at 11:10:33 AM UTC-6, Keith Thompson wrote:
> supercat writes:
> [...]
> > My approach would not require a compiler to track what kinds of conversions
> > have been done with objects, but rather regard conversions as a type of
> > sequenced *action* which will not generate any code, but must be carried
> > through the optimizer as an action which doesn't generate any code, somewhat
> > like an empty asm directive.
>
> If you're talking about conversions in general, that's clearly absurd.
> For example, an int-to-double conversion must generate some code (unless
> the result can be determined at compile time).
I was focused on pointer conversions.
> If you're talking only about pointer conversions, apparently you're
> proposing that the language should require that all pointer types have
> the same representation. Is that what you're proposing?
Conversions between types with differing representations, whether they
be pointers or otherwise, will need to be carried through the optimizer
as actual code. My point was pointer conversions should be carried
through the optimizer *whether they generate code or not*.
Many platforms' Implementation-Defined aspects are specified in ways that
allow code to be simpler than would be possible otherwise. For example,
many platforms define their representation for NULL such that code needing
100 void pointers all initialized to null can use
void **p = calloc(sizeof (void*), 100);
rather than having to null out all the pointers using a loop. The Standard
does not provide any means by which code can refuse compilation on platforms
where pointers to specific types are not representation-compatible with
void*, but code which only needs to work on implementations which specify
matching representations can be simpler and more efficient than code which
needs to work on implementations where that isn't the case. Implementations
where pointer representations are not consistent are very rare, and only
programmers with a specific need to support such rare implementations should
forego the advantages of common ones.
[toc] | [prev] | [next] | [standalone]
| From | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2017-03-02 19:44 +0000 |
| Message-ID | <slrnobgth1.88q.nw@granicus.if.org> |
| In reply to | #105282 |
On 2017-03-01, Keith Thompson <kst-u@mib.org> wrote: > supercat@casperkitty.com writes: >> My approach would not require a compiler to track what kinds of conversions >> have been done with objects, but rather regard conversions as a type of >> sequenced *action* which will not generate any code, but must be carried >> through the optimizer as an action which doesn't generate any code, somewhat >> like an empty asm directive. > > If you're talking about conversions in general, that's clearly absurd. > For example, an int-to-double conversion must generate some code (unless > the result can be determined at compile time). Is this strictly true? I am envisioning a system where an integer has padding in which the information needed for the same bytes to represent a double are kept. Such a scheme might require sizeof (int) to be unreasonably large, or have a bit in the double representation meaning "exactly convertable to int", but for the DS9000 that's presumably a feature, not a bug. It's possible then that the int-to-double case would be a no-op while the double-to-int case wouldn't (necessarily) be. If I've done the math right, the exact integer portion of a double meeting the minimum requirements would need 158 bits, or 20 octets, so sizeof (int) on such a machine (assuming CHAR_BIT 8) might be somewhere above 20, 24 or 32 seem probable. -- nw
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-02 12:05 -0800 |
| Message-ID | <lno9xjbg1z.fsf@kst-u.example.com> |
| In reply to | #105328 |
Nathan Wagner <nw@hydaspes.if.org> writes:
> On 2017-03-01, Keith Thompson <kst-u@mib.org> wrote:
>> supercat@casperkitty.com writes:
>
>>> My approach would not require a compiler to track what kinds of conversions
>>> have been done with objects, but rather regard conversions as a type of
>>> sequenced *action* which will not generate any code, but must be carried
>>> through the optimizer as an action which doesn't generate any code, somewhat
>>> like an empty asm directive.
>>
>> If you're talking about conversions in general, that's clearly absurd.
>> For example, an int-to-double conversion must generate some code (unless
>> the result can be determined at compile time).
>
> Is this strictly true?
Strictly? No. Practically? Yes.
[...]
--
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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-02 04:19 -0600 |
| Message-ID | <5P-dnc8XAK5abCrFnZ2dnUU7-Y_NnZ2d@supernews.com> |
| In reply to | #105250 |
supercat@casperkitty.com wrote:
>>
>> It looks like your type aliasing rules vary depending on what type
>> conversions have been done. Is that right? But compilers don't
>> always track pointers and objects through chains of function calls,
>> which might in any case be in different compilation units. Data flow
>> analysis is always imperfect.
>
> My approach would not require a compiler to track what kinds of
> conversions have been done with objects, but rather regard
> conversions as a type of sequenced *action* which will not generate
> any code, but must be carried through the optimizer as an action
> which doesn't generate any code, somewhat like an empty asm
> directive.
I don't think that would really work, given that it doesn't matter
when the cast was done but which objects it affected.
You could simply regard all pointer casts and accesses as legitimate
and replace GCC's type-based aliasing code with flow-sensitive
points-to analysis. (GCC already does some flow-sensitive analysis,
but AFAICR it's local, not over a whole program, and is only done for
SSA-based passes.) For this to work really well you'd have to
optimize the whole program, and obviously this presents problems with
shared libraries. The careful use of restrict qualifiers at library
call boundaries would help with this. Chapter 10 of Muchnick is an
introduction.
>> Consider a compilation unit with this function:
>>
>> long f(long *a, double *b) {
>> long result = *a;
>> g(b);
>> return result;
>> }
>>
>> Do *a and *b alias or not? We need a way to know.
>
> Unless the compiler knows that g() can't possibly modify anything of type
> "long", it would need to read "a" before calling g. The only way in which
> my rule would affect the above example would be if an implementation kept
> a list of what pointer types a function accesses.
Sorry, it was a bad example, but you take my point: at the entry point
of a function you need to know whether its arguments may alias. You
don't know anything about anything else: this is a single compilation
unit.
So, here's a simpler example:
long f(long *a, double *b) {
We're at the start of a function. This is all the compiler can see.
Do a and b alias or not?
As it says in DR #236, "The spirit of the type-based aliasing rule is
to help the optimizer to compute aliasing relationship without
knowledge about the rest of the program." An alias oracle needs to be
able, when passed two objects, to answer the question "are these
members of the same alias set?" If they are, then you have a
dependence between accesses, so they have to be kept in order. If
they aren't, accesses can move.
>> So what's stopping you from implementing this scheme? You say it's
>> not difficult to do, but there's no substitute for working code.
>> Then you could run a bunch of benchmarks and measure the performance
>> change. You'd have something real to talk about.
>
> I don't know what compiler would be a good one to base it on. GCC
> has grown horrendously complicated. I've been thinking of targeting
> TCC but it targets x86 and I don't know how easily it would be
> adaptable to ARM Cortex-M0 which is the platform I'm really
> interested in.
I'm trying to interpret that. I think you're saying that to do what
you suggest would not really be difficult, but it would be too
difficult to do it in GCC bacuse GCC is very complicated. But there's
no point doing anything like this in a toy compiler, because you need
a baseline to compare with. And to say that it's not hard but it is
difficult in a real industrial-strength compiler is at best
meaningless: this conversation is about such compilers.
>> OK, I see. I imagine that if I were to investigate I'd agree with
>> them. But why is this in any way interesting? Even if it's possible
>> to interpret C89 in a way that supports your case, it's an obsolete
>> standard, and nobody is going to bother to clarify it.
>
> You may regard C89 as obsolete, but the embedded world is ruled by
> C89 plus a few C99 extensions thrown in, but not the "effective
> type" rules.
I'm not sure that I agree that the entire world of embedded
programming is ruled by C89, but I'll let that pass.
The problem with arguing about what C89 means is that whatever
mistakes and ambiguities C89 had are not going to be fixed or even
clarified because it has been superseded. Where clarifications and
corrections to the aliasing rules have been sought, they have been
made to later revisions of the standard. It doesn't make sense for
anyone to rely on an interpretation of what C89 might have meant,
especially if that interpretation disagrees with that of compiler
writers. Even if they are "wrong", for some value of "wrong".
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-02 06:06 -0800 |
| Message-ID | <967f28b3-5dee-46c9-a6ed-060e1d7c8703@googlegroups.com> |
| In reply to | #105315 |
On Thursday, March 2, 2017 at 4:20:11 AM UTC-6, Andrew Haley wrote:
> supercat wrote:
> I don't think that would really work, given that it doesn't matter
> when the cast was done but which objects it affected.
In well-written rules it should matter, since knowledge of when type
conversions occur indicates what kinds of transforms will and will not
be compatible with the semantics a programmer is likely to require.
Consider test1 and test2 below, assuming mtype1 and mtype2 are non-array
types of some sort:
typedef uniontype { mtype1 member1; mtype2 member2; };
void test1(uniontype *unionptr1, uniontype *unionptr2)
{
proc1(&unionptr1->member1);
proc2(&unionptr2->member2);
}
void helper(mtype1 *p1, mtype2 *p2) { proc1(p1); proc2(p2); }
void test2(uniontype *unionptr1, uniontype *unionptr2)
{
helper(&unionptr1->member1, &unionptr2->member2)
}
The Standard does not attach any significance to the act of taking the
address of a union member--likely because the Common Initial Sequence rule
would be rendered useless if such action always switched the active member--
and would thus treat test1 and test2 as equivalent, but I'd suggest that
in test1 the invocations of proc1 and proc2 should be fully sequenced while
in test2 a compiler should be able to arbitrarily interleave them. That
seems much more useful than saying that in both cases a compiler would be
allowed to move writes from test1 past reads in test2, and writes in either
past writes in the either, but would be required to keep reads in test1
ahead of writes in test2.
> You could simply regard all pointer casts and accesses as legitimate
> and replace GCC's type-based aliasing code with flow-sensitive
> points-to analysis. (GCC already does some flow-sensitive analysis,
> but AFAICR it's local, not over a whole program, and is only done for
> SSA-based passes.) For this to work really well you'd have to
> optimize the whole program, and obviously this presents problems with
> shared libraries. The careful use of restrict qualifiers at library
> call boundaries would help with this. Chapter 10 of Muchnick is an
> introduction.
What I'm calling for doesn't require anything nearly that fancy. If a
compiler sees a pointer conversion and all uses of the resulting pointer,
treat the uses it can see as though they happened with the original type.
Otherwise, treat the conversion itself much like a potential access of
the original type.
> Sorry, it was a bad example, but you take my point: at the entry point
> of a function you need to know whether its arguments may alias. You
> don't know anything about anything else: this is a single compilation
> unit.
I wrote another follow-up to you which revisited that example; it's perhaps
more illustrative than you realized, since I think my approach would be
able to move the read of *a past the function in more cases than are allowable
under C99 or C11.
> So, here's a simpler example:
>
> long f(long *a, double *b) {
>
> We're at the start of a function. This is all the compiler can see.
> Do a and b alias or not?
If the compiler can't see either of them get cast within f, it need not
worry about aliasing. If it in-lines a function wherein they are cast, it
can treat that as a cast within f. If it calls a function it can't see,
it would have no reason to know or care whether that function used cross-
type aliasing to access things or whether it did so via some other means.
> As it says in DR #236, "The spirit of the type-based aliasing rule is
> to help the optimizer to compute aliasing relationship without
> knowledge about the rest of the program."
Indeed.
> An alias oracle needs to be
> able, when passed two objects, to answer the question "are these
> members of the same alias set?" If they are, then you have a
> dependence between accesses, so they have to be kept in order. If
> they aren't, accesses can move.
The concept of a fixed "alias set" is fundamentally incompatible with system
proogramming, and isn't really compatible with the C99/C11 standards either.
If one were to adjust the aliasing rules of the C Standard so that any storage
which ever acquired an effective type would be permanently bound to that type,
one would have a language which would be better for some purposes (e.g. high0
end number crunching) than C is now, but totally unsuitable for others (like
systems programming).
Otherwise, why try to classify things into alias sets and then use those to
infer required orderings, rather than keeping track of ordering requirements
more directly?
> > I don't know what compiler would be a good one to base it on. GCC
> > has grown horrendously complicated. I've been thinking of targeting
> > TCC but it targets x86 and I don't know how easily it would be
> > adaptable to ARM Cortex-M0 which is the platform I'm really
> > interested in.
>
> I'm trying to interpret that. I think you're saying that to do what
> you suggest would not really be difficult, but it would be too
> difficult to do it in GCC bacuse GCC is very complicated. But there's
> no point doing anything like this in a toy compiler, because you need
> a baseline to compare with. And to say that it's not hard but it is
> difficult in a real industrial-strength compiler is at best
> meaningless: this conversation is about such compilers.
In case you haven't noticed, the vast majority of embeded code uses gcc with
-fno-strict-aliasing, and gcc is really not very good in that mode. The
reason I haven't done such mods in gcc is that while I would expect the mods
to be simple to anyone familiar with gcc's inner workings, the time required
to gain such an understanding would be rather huge.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-02 10:16 -0600 |
| Message-ID | <1PydnQg6VPbU2CXFnZ2dnUU7-dPNnZ2d@supernews.com> |
| In reply to | #105319 |
supercat@casperkitty.com wrote:
> On Thursday, March 2, 2017 at 4:20:11 AM UTC-6, Andrew Haley wrote:
>> supercat wrote:
>> I don't think that would really work, given that it doesn't matter
>> when the cast was done but which objects it affected.
>
> In well-written rules it should matter, since knowledge of when type
> conversions occur indicates what kinds of transforms will and will
> not be compatible with the semantics a programmer is likely to
> require.
>
> Consider test1 and test2 below, assuming mtype1 and mtype2 are non-array
> types of some sort:
>
> typedef uniontype { mtype1 member1; mtype2 member2; };
> void test1(uniontype *unionptr1, uniontype *unionptr2)
> {
> proc1(&unionptr1->member1);
> proc2(&unionptr2->member2);
> }
>
> void helper(mtype1 *p1, mtype2 *p2) { proc1(p1); proc2(p2); }
> void test2(uniontype *unionptr1, uniontype *unionptr2)
> {
> helper(&unionptr1->member1, &unionptr2->member2)
> }
>
> The Standard does not attach any significance to the act of taking
> the address of a union member--likely because the Common Initial
> Sequence rule would be rendered useless if such action always
> switched the active member-- and would thus treat test1 and test2 as
> equivalent, but I'd suggest that in test1 the invocations of proc1
> and proc2 should be fully sequenced while in test2 a compiler should
> be able to arbitrarily interleave them.
It makes no difference because one is simply the result of an inlining
substitution on the other. Unless you want to forbid inlining, that
is.
>> You could simply regard all pointer casts and accesses as legitimate
>> and replace GCC's type-based aliasing code with flow-sensitive
>> points-to analysis. (GCC already does some flow-sensitive analysis,
>> but AFAICR it's local, not over a whole program, and is only done for
>> SSA-based passes.) For this to work really well you'd have to
>> optimize the whole program, and obviously this presents problems with
>> shared libraries. The careful use of restrict qualifiers at library
>> call boundaries would help with this. Chapter 10 of Muchnick is an
>> introduction.
>
> What I'm calling for doesn't require anything nearly that fancy. If
> a compiler sees a pointer conversion and all uses of the resulting
> pointer, treat the uses it can see as though they happened with the
> original type.
To some extent that is flow-sensitive points-to analysis. And
besides, what if the pointer conversion happens in a place the
compiler can't see?
>> So, here's a simpler example:
>>
>> long f(long *a, double *b) {
>>
>> We're at the start of a function. This is all the compiler can see.
>> Do a and b alias or not?
>
> If the compiler can't see either of them get cast within f, it need
> not worry about aliasing.
Is that a "yes" or a "no"? It's important.
> If it in-lines a function wherein they are cast, it can treat that
> as a cast within f. If it calls a function it can't see, it would
> have no reason to know or care whether that function used cross-
> type aliasing to access things or whether it did so via some other
> means.
If the caller used pointer casts, a and b might well point to the same
memory. You really do need to know if a and b might alias if you want
to optimize memory accesses.
>> As it says in DR #236, "The spirit of the type-based aliasing rule is
>> to help the optimizer to compute aliasing relationship without
>> knowledge about the rest of the program."
>
> Indeed.
>
>> An alias oracle needs to be able, when passed two objects, to
>> answer the question "are these members of the same alias set?" If
>> they are, then you have a dependence between accesses, so they have
>> to be kept in order. If they aren't, accesses can move.
>
> The concept of a fixed "alias set" is fundamentally incompatible
> with system proogramming,
Well, that's an opinion you're entitled to have. Everybody else is
free to disagree.
>> I think you're saying that to do what you suggest would not really
>> be difficult, but it would be too difficult to do it in GCC bacuse
>> GCC is very complicated. But there's no point doing anything like
>> this in a toy compiler, because you need a baseline to compare
>> with. And to say that it's not hard but it is difficult in a real
>> industrial-strength compiler is at best meaningless: this
>> conversation is about such compilers.
>
> In case you haven't noticed, the vast majority of embeded code uses
> gcc with -fno-strict-aliasing,
No, I haven't. But in any case I haven't take a survey of the vast
majority of embedded code, and I doubt that you have either.
> and gcc is really not very good in that mode. The reason I haven't
> done such mods in gcc is that while I would expect the mods to be
> simple to anyone familiar with gcc's inner workings, the time
> required to gain such an understanding would be rather huge.
So, you don't know how GCC works, but you're confident enough to say
it's not difficult to do what you suggest. Is there some other
industrial-strength compiler you know well enough to implement your
ideas?
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-02 15:32 -0800 |
| Message-ID | <cf4d6e38-e63f-47ec-9d9b-dd9bc8c18899@googlegroups.com> |
| In reply to | #105325 |
On Thursday, March 2, 2017 at 10:16:21 AM UTC-6, Andrew Haley wrote:
> supercat wrote:
> > Consider test1 and test2 below, assuming mtype1 and mtype2 are non-array
> > types of some sort:
> >
> > typedef uniontype { mtype1 member1; mtype2 member2; };
> > void test1(uniontype *unionptr1, uniontype *unionptr2)
> > {
> > proc1(&unionptr1->member1);
> > proc2(&unionptr2->member2);
> > }
> >
> > void helper(mtype1 *p1, mtype2 *p2) { proc1(p1); proc2(p2); }
> > void test2(uniontype *unionptr1, uniontype *unionptr2)
> > {
> > helper(&unionptr1->member1, &unionptr2->member2)
> > }
> >
> > The Standard does not attach any significance to the act of taking
> > the address of a union member--likely because the Common Initial
> > Sequence rule would be rendered useless if such action always
> > switched the active member-- and would thus treat test1 and test2 as
> > equivalent, but I'd suggest that in test1 the invocations of proc1
> > and proc2 should be fully sequenced while in test2 a compiler should
> > be able to arbitrarily interleave them.
>
> It makes no difference because one is simply the result of an inlining
> substitution on the other. Unless you want to forbid inlining, that
> is.
The second form, with helper inlined, would be equivalent to:
void test2(uniontype *unionptr1, uniontype *unionptr2)
{
mtype1 *p1 = &unionptr1->member1; // Unsequenced with regard to line below
mtype2 *p2 = &unionptr2->member2; // Unsequenced with regard to line above
proc1(p1);
proc2(p2);
}
A compiler which was looking at the end of p1 and the start of p2 would
see nothing between them that would suggest that any writes performed in
p1 could not be moved behind of reads performed in p2, nor that reads
performed in p2 could not be moved ahead relative to writes in p1.
Rewriting the first to use temporaries in similar fashion would be:
void test2(uniontype *unionptr1, uniontype *unionptr2)
{
mtype1 *p1 = &unionptr1->member1;
proc1(p1);
mtype2 *p2 = &unionptr2->member2; // Occurs after proc(p1)
proc2(p2);
}
Now a compiler that looks at the end of p1 and the start of p2 would see
that they are separated by a conversion which involves a union of types
mtype1 and mtype2. Such a conversion should serve as a barrier between
operations on the two types.
> > What I'm calling for doesn't require anything nearly that fancy. If
> > a compiler sees a pointer conversion and all uses of the resulting
> > pointer, treat the uses it can see as though they happened with the
> > original type.
>
> To some extent that is flow-sensitive points-to analysis. And
> besides, what if the pointer conversion happens in a place the
> compiler can't see?
If a function performs an "overt" type conversion, then either the metadata
for the function would need to report that it performs a conversion from
that type, requiring the caller to not to accelerate any accesses of that
type which appear between the call and the next hoist point, or else it
must report that the function might read or write things of that type and
callers that see such a report must defer acceleration of accesses as they
would following a conversion. The situation is really not much different
from any other kind of access a function might perform.
If a function performs "covert" type conversion, e.g.
mtype2 *evilConvert(mtype1 *p)
{
union {mtype1 *p1; mtype2 *p2; } sneaky;
sneaky.p1 = p;
return sneaky.p2;
}
a compiler would be under no obligation to notice such type conversion.
Either the pointer would need to have originated as an mtype2, the
pointer would need to be converted back to mytype1 before anything other
than a CIS member is accessed via the pointer, or there would need to be
visible conversion(s) in addition to the hidden one(s) such that a compiler
would have reason to expect any aliasing that might occur between any
accesses performed before the call and any that might occur afterward.
I'm not asking compilers to be omniscient--all I'm asking is that they
not turn a blind eye to things that are right in front of them.
> >> So, here's a simpler example:
> >>
> >> long f(long *a, double *b) {
> >>
> >> We're at the start of a function. This is all the compiler can see.
> >> Do a and b alias or not?
> >
> > If the compiler can't see either of them get cast within f, it need
> > not worry about aliasing.
>
> Is that a "yes" or a "no"? It's important.
If f() contains no visible type conversions and does not inline-expand nor
call functions which contain visible type conversions, then the answer is
a straight up no--unlike in C99/C11, which requires that compilers allow
for the possibility that an object might get read as one type and then
written as the other. If f() does contain visible type conversions involving
long* or double*, or calls an external function which reports that it does
so, those would limit the optimizations that f() could perform following
such conversion or call.
> > If it in-lines a function wherein they are cast, it can treat that
> > as a cast within f. If it calls a function it can't see, it would
> > have no reason to know or care whether that function used cross-
> > type aliasing to access things or whether it did so via some other
> > means.
>
> If the caller used pointer casts, a and b might well point to the same
> memory. You really do need to know if a and b might alias if you want
> to optimize memory accesses.
If the caller used pointer casts, then for behavior to be defined by my
rules the only objects which could be accessed by both types in the absence
of further casts would be those which are not written within the function
(my rules would allow a compiler to arbitrarily interleave accesses
involving the two types, but if all accesses are reads such interleaving
would have no effect).
> >> An alias oracle needs to be able, when passed two objects, to
> >> answer the question "are these members of the same alias set?" If
> >> they are, then you have a dependence between accesses, so they have
> >> to be kept in order. If they aren't, accesses can move.
> >
> > The concept of a fixed "alias set" is fundamentally incompatible
> > with system proogramming,
>
> Well, that's an opinion you're entitled to have. Everybody else is
> free to disagree.
Unless I'm misunderstanding your use of the term, a real "fixed alias set"
would imply that if "p" is of type "double", then given the code "*p=123.0;"
a compiler could perform the associated store at any time it wants until the
next time an attempt is made to access that storage as type "double". Such
freedom would imply that any code which ever tried to use that storage for
some other type could find it clobbered by a deferred "double" write.
Can you explain how someone on a freestanding system without "malloc"/"free"
could possibly synthesize such functionality without being able to
efficiently guarantee that all actions upon a block of storage by one
owner would behave as though completed before any actions by the next
owner, even if the old and new owners wanted to use the storage through
different types?
>
> >> I think you're saying that to do what you suggest would not really
> >> be difficult, but it would be too difficult to do it in GCC bacuse
> >> GCC is very complicated. But there's no point doing anything like
> >> this in a toy compiler, because you need a baseline to compare
> >> with. And to say that it's not hard but it is difficult in a real
> >> industrial-strength compiler is at best meaningless: this
> >> conversation is about such compilers.
> >
> So, you don't know how GCC works, but you're confident enough to say
> it's not difficult to do what you suggest. Is there some other
> industrial-strength compiler you know well enough to implement your
> ideas?
I would expect that gcc at some point generates a syntax tree, explicit
pointer casts would be fairly easily recognizable as nodes thereon,
and that a node and its child would be labeled with the new and old
types, respectively. Replace each such node with an asm/clobber directive
indicating that no accesses to objects of the old type which happen before
the directive can be moved after it, and no accesses of the new type which
happen after the directive can be moved before it.
That would be a bit of a sledge-hammer approach, and I'm not sure there
wouldn't be some corner cases where gcc wouldn't try to move up something
that followed the directive to a spot which was between the directive
and the next access to the pointer produced thereby, but it should work
well enough to process various samples of code and find out how often
any loss of optimizations would be worth worrying about.
I wouldn't be surprised if the design of gcc would make it hard to apply
more selective barriers. On the other hand, even if a mode which applied
the barriers ruthlessly would give up half of the optimizations which
would could otherwise be achieved with -fstrict-aliasing, that would still
be a major improvement compared with giving up 100% of such optimizations.
Of more interest to high-end programmers should be the possibility that
recognizing casts as barriers would likely eliminate many programs'
reliance upon C99/C11 guarantee that accesses won't get moved behind
foreign-type writes.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-03 04:20 -0600 |
| Message-ID | <krGdnUG5Efjv3iTFnZ2dnUU7-SXNnZ2d@supernews.com> |
| In reply to | #105338 |
supercat@casperkitty.com wrote:
> On Thursday, March 2, 2017 at 10:16:21 AM UTC-6, Andrew Haley wrote:
>> supercat wrote:
>
>> >> So, here's a simpler example:
>> >>
>> >> long f(long *a, double *b) {
>> >>
>> >> We're at the start of a function. This is all the compiler can see.
>> >> Do a and b alias or not?
>> >
>> > If the compiler can't see either of them get cast within f, it need
>> > not worry about aliasing.
>>
>> Is that a "yes" or a "no"? It's important.
>
> If f() contains no visible type conversions and does not
> inline-expand nor call functions which contain visible type
> conversions,> then the answer is a straight up no--unlike in
> C99/C11, which requires that compilers allow for the possibility
> that an object might get read as one type and then written as the
> other.
For something simple like this
long f(long *a, double *b) {
for (long i = 0; i < *a; i++)
b[i] = i;
}
we need to know if we can hoist *a out of the loop. I'd want the
behaviour of this function to be well-enough defined that it didn't
slow down if, e.g. if it got inlined and the compiler noticed that on
some path of execution a and b might be aliases. That latter part is
important: a compiler can't solve the halting problem, so there will
be many potential paths which the programmer knows are impossible, but
the compiler can't know that.
But I don't think that any of this makes any sense anyway. It means
that some games with pointer casts would "work" when the compiler was
doing heavy optimization with inter-procedural analysis and fail to
work when that analysis was turned off. That's why I wnt you to
actually try to implement this: there's no substitute for working
code.
> Unless I'm misunderstanding your use of the term, a real "fixed
> alias set" would imply that if "p" is of type "double", then given
> the code "*p=123.0;" a compiler could perform the associated store
> at any time it wants until the next time an attempt is made to
> access that storage as type "double".
Or even never write it at all. Within the limits of what the standard
says, yes. Bear in mind, though, that character pointers alias
everything and alias sets overlap and nest.
>> So, you don't know how GCC works, but you're confident enough to say
>> it's not difficult to do what you suggest. Is there some other
>> industrial-strength compiler you know well enough to implement your
>> ideas?
>
> I would expect that gcc at some point generates a syntax tree,
> explicit pointer casts would be fairly easily recognizable as nodes
> thereon, and that a node and its child would be labeled with the new
> and old types, respectively. Replace each such node with an
> asm/clobber directive indicating that no accesses to objects of the
> old type which happen before the directive can be moved after it,
> and no accesses of the new type which happen after the directive can
> be moved before it.
I take it, then, that the answers to those questions are "yes" and
"no", respectively.
I still don't see how this makes any sense: the time at which a
pointer cast happens does not matter, whereas the time when accesses
based on it does, but never mind.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-03 05:19 -0800 |
| Message-ID | <3ff11628-3b92-4d0e-810a-8798a6fbc2df@googlegroups.com> |
| In reply to | #105342 |
On Friday, March 3, 2017 at 4:20:47 AM UTC-6, Andrew Haley wrote:
> For something simple like this
>
> long f(long *a, double *b) {
> for (long i = 0; i < *a; i++)
> b[i] = i;
> }
>
> we need to know if we can hoist *a out of the loop. I'd want the
> behaviour of this function to be well-enough defined that it didn't
> slow down if, e.g. if it got inlined and the compiler noticed that on
> some path of execution a and b might be aliases. That latter part is
> important: a compiler can't solve the halting problem, so there will
> be many potential paths which the programmer knows are impossible, but
> the compiler can't know that.
My rules would allow the fetch of *a to be hoisted to the start of the
loop even if a cast from double* to long* were performed within f(); a
compiler would only be required to acknowledge aliasing within a loop
between types that are involved in conversions *within the loop*. Since
there are no conversions within the body of the loop, a compiler could
hoist away.
> But I don't think that any of this makes any sense anyway. It means
> that some games with pointer casts would "work" when the compiler was
> doing heavy optimization with inter-procedural analysis and fail to
> work when that analysis was turned off. That's why I wnt you to
> actually try to implement this: there's no substitute for working
> code.
I'm not sure what I need to do to make my rules clearer, since you seem to
think I'm requiring a lot more of the compiler than I am. It would have
been nicer if the Standard had specified a construct which could specify
the start and end of an aliasing "window", since that would allow compilers
to freely move accesses that don't cross window boundaries, without having
to look for conflicting accesses as far back as previous start of a function
or loop, but of course the Standard provides no such feature.
> > Unless I'm misunderstanding your use of the term, a real "fixed
> > alias set" would imply that if "p" is of type "double", then given
> > the code "*p=123.0;" a compiler could perform the associated store
> > at any time it wants until the next time an attempt is made to
> > access that storage as type "double".
>
> Or even never write it at all. Within the limits of what the standard
> says, yes. Bear in mind, though, that character pointers alias
> everything and alias sets overlap and nest.
Never writing it at all wouldn't be a problem. Writing it late, in such
fashion as to clobber the storage when it's being used for something else,
is.
Under the present rules, character-type accesses are brutal from an aliasing
perspective. My rule would ease the character type exception (in non-
conforming mode) for code which only needed to use such accesses for aliasing
in the same scenarios as I would allow other types.
> I still don't see how this makes any sense: the time at which a
> pointer cast happens does not matter, whereas the time when accesses
> based on it does, but never mind.
The Standard pays no heed to the timing of pointer conversions, true. It
does not forbid compilers from doing so.
If some code acquires a void* which identifies a word-aligned 4,000,000-byte
block of storage that it would like to use as a hash table of 32-bit values,
and would be perfectly happy with any initial bit pattern therein, what
construct should it use to get a uint32_t* which can be used to efficiently
access 1,000,000 values of type uin32_t?
If all future accesses to that storage are going to be through pointers
derived from that void*, I would suggest that any implementation suitable for
system programming should allow code to start using the storage quickly and
easily. The Standard doesn't require that such a thing be possible, but it
makes no effort to require that all implementations be suitable for system
programming. By what means would you suggest that code should fulfill such
a requirement, if not by observing that the cast to uint32_t* came after the
last use of float* (or other types) to access the storage, and there are
no signs that the storage is going to be used as float* (or other types)
"without warning" in future?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-03 08:22 -0800 |
| Message-ID | <5b185d28-a190-4e7e-baf9-0e0fedd3dfca@googlegroups.com> |
| In reply to | #105342 |
On Friday, March 3, 2017 at 4:20:47 AM UTC-6, Andrew Haley wrote:
> I still don't see how this makes any sense: the time at which a
> pointer cast happens does not matter, whereas the time when accesses
> based on it does, but never mind.
If "u" is a pointer to a union with members "v1" of type "t1", and "v2" of
type "t2", and there exist functions
t1* pass_through_t1(t1 *p) { return p; }
t2* pass_through_t2(t2 *p) { return p; }
is there anything in the text of the Standard that would suggest that any
behavior which would be defined when using the lvalue expression "(u->t1)"
would not be identically defined if the lvalue expression
"(*(pass_through_t1(&u->t1)))" were substituted (and likewise for v2/t2)?
From what I can tell, there are two ways an implementation could ensure that
the latter behaves identically to the former in all cases where the former
is defined: (1) assume that any access via pointer of type t1* which is
followed by an access via pointer of type t2* might alias it, or (2) treat
the pointer conversion implied by &u->t1 or &u->t2 as a sequenced action
and honor the aliasing implications thereof.
The Standard doesn't require that the above conversions through union types
be regarded as sequenced actions, since an implementation which would assume
accesses via t1* and t2* might alias wouldn't need to do so. On the other
hand, I see no way a compiler could uphold the equivalence between union-
member lvalues and the objects addressed by pointers to them without either
making pessimistic aliasing assumptions or recognizing sequencing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-02 19:34 +0100 |
| Message-ID | <o99og7$tci$1@dont-email.me> |
| In reply to | #105319 |
On 02/03/17 15:06, supercat@casperkitty.com wrote: > > In case you haven't noticed, the vast majority of embeded code uses gcc with > -fno-strict-aliasing, and gcc is really not very good in that mode. > You are very quick to tell us about the "vast majority of embedded code" - it's all written in C89, it uses "-fno-strict-aliasing" in gcc, it requires pointer casts all over the place, it needs highly optimised functions that sometime return unspecified values, and so on. None of your claims ever seem to match up with my experience. If this sort of thing were so common, surely I would have met examples in the last 20 years or so. I can only think of /one/ program that needs the "-fno-strict-aliasing" flag - the Linux kernel. It needs that because it messes about with pointer casts instead of using other techniques. Linus Torvalds feels that pointer casts are a good idea, and give the clearest and most efficient code. That's fine - the kernel is written in a variant of C that defines accessing objects through different pointer types, and gcc provides switches to support that C variant. The C standards have always intended for implementations to be able to extend C, and this is one way to do it. But other code I have seen (and written) that needs to make occasional accesses through cast pointer use other techniques to make the code safe - volatiles, memory barriers, memcpy, etc. Some of these are also implementation dependent, or at least rely on the compiler being able to optimise memcpy in order to generate efficient code. They don't use global brute force methods like "-fno-strict-alias". And I have also seen more code than I'd like that has comments like "this code does not work with optimisation enabled". Perhaps -fno-strict-alias would help for such code - but usually there are lots of things wrong and the code is broken in many ways. So unless you can provide concrete data, solid examples, statistics, or at the very least a second opinion, I think you should stop making such exaggerated claims.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-02 08:02 -0800 |
| Message-ID | <e64ecc35-02e9-47c2-9a97-dc27265048cb@googlegroups.com> |
| In reply to | #105315 |
On Thursday, March 2, 2017 at 4:20:11 AM UTC-6, Andrew Haley wrote: > The problem with arguing about what C89 means is that whatever > mistakes and ambiguities C89 had are not going to be fixed or even > clarified because it has been superseded. The authors of the Standard want to allow implementations to be suitable for as many purposes as possible. If the present version of Standard provides a behavioral guarantee which is essential for some purposes, but weakening the guarantee would make the language more suitable some other purposes, a decision by the Committee to weaken the guarantee should not be seen as a judgment that compilers could remain suitable for the purposes served by the old standard without continuing to honor that guarantee. Further, the authors of C89 seem to have sought to avoid redundancy. In the absence of modern interpretations of aliasing rules, specifying the relationship between union and structure pointers, and specifying the CIS rule for unions, would imply that code which receives a pointer to a structure and didn't know where it came from would have no choice but to apply the same CIS rule to structure pointers. Specifying the CIS rule for structures would not imply that unions whose address wasn't taken would need to behave likewise. The real purposes of the CIS rule has always centered around struct pointers (the ability to access struct pointers via common initial sequence goes back at least to January 1974); the most plausible reason it is not defined in such terms in C89 is that such definition would have meant needlessly specifying it twice (once for structures and once for unions).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-02 10:54 -0600 |
| Message-ID | <uK2dnUF8XbfG0yXFnZ2dnUU7-aXNnZ2d@supernews.com> |
| In reply to | #105324 |
supercat@casperkitty.com wrote: > On Thursday, March 2, 2017 at 4:20:11 AM UTC-6, Andrew Haley wrote: >> The problem with arguing about what C89 means is that whatever >> mistakes and ambiguities C89 had are not going to be fixed or even >> clarified because it has been superseded. > > The authors of the Standard want to allow implementations to be > suitable for as many purposes as possible. If the present version > of Standard provides a behavioral guarantee which is essential for > some purposes, but weakening the guarantee would make the language > more suitable some other purposes, a decision by the Committee to > weaken the guarantee should not be seen as a judgment that compilers > could remain suitable for the purposes served by the old standard > without continuing to honor that guarantee. Perhaps not, but this is pure conjecture. Where there are disagreements about the manining of C89 we're never going to know what was intended, and it's never going to be clarified. It's not impossible that they never thought about it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-02 16:35 -0800 |
| Message-ID | <b77fa8c9-cfa2-4b6e-b700-db566bffd024@googlegroups.com> |
| In reply to | #105326 |
On Thursday, March 2, 2017 at 10:55:04 AM UTC-6, Andrew Haley wrote: > > The authors of the Standard want to allow implementations to be > > suitable for as many purposes as possible. If the present version > > of Standard provides a behavioral guarantee which is essential for > > some purposes, but weakening the guarantee would make the language > > more suitable some other purposes, a decision by the Committee to > > weaken the guarantee should not be seen as a judgment that compilers > > could remain suitable for the purposes served by the old standard > > without continuing to honor that guarantee. > > Perhaps not, but this is pure conjecture. Where there are > disagreements about the manining of C89 we're never going to know what > was intended, and it's never going to be clarified. It's not > impossible that they never thought about it. No doubt some guarantees were removed because the authors of the Standard decided they were broader than they needed to be (e.g. C89's rule allowing a pointer of a structure type to access objects of member types is needed to allow "structPtr->member", but nothing in the text of the rule limits it to member types which are actually used within the expression). I'm not claiming that no guarantees were ever removed for such purposes. What I object to is the apparent belief that the authors of the Standard intended to mandate all behaviors a compiler must support to make it suitable for any particular purpose, and that a decision not to mandate a behavior implies a judgement that no programmer in any field should have a right to expect it. Further, even if a C89 behavioral mandate that turned out to be useful for some kinds of application was totally accidental, that wouldn't imply that a compiler which ceased to uphold such a mandate wouldn't be less suitable for those kinds of applications than one which continued to uphold it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-16 18:30 -0700 |
| Message-ID | <kfnefwr95xo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #105326 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > supercat@casperkitty.com wrote: >> On Thursday, March 2, 2017 at 4:20:11 AM UTC-6, Andrew Haley wrote: >>> The problem with arguing about what C89 means is that whatever >>> mistakes and ambiguities C89 had are not going to be fixed or even >>> clarified because it has been superseded. >> >> The authors of the Standard want to allow implementations to be >> suitable for as many purposes as possible. If the present version >> of Standard provides a behavioral guarantee which is essential for >> some purposes, but weakening the guarantee would make the language >> more suitable some other purposes, a decision by the Committee to >> weaken the guarantee should not be seen as a judgment that compilers >> could remain suitable for the purposes served by the old standard >> without continuing to honor that guarantee. > > Perhaps not, but this is pure conjecture. Where there are > disagreements about the manining of C89 we're never going to know what > was intended, and it's never going to be clarified. It's not > impossible that they never thought about it. I agree with this as a general rule. In some cases though what was meant can be gleaned from various historical documents, eg, Defect Reports or notes from the twice-yearly meetings. However those cases tend to be in specific areas, not on vague abstract principles.
[toc] | [prev] | [next] | [standalone]
Page 10 of 27 — ← Prev page 1 … 8 9 [10] 11 12 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web