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 9 of 27 — ← Prev page 1 … 7 8 [9] 10 11 … 27 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-24 10:01 -0800 |
| Message-ID | <38c2687d-f727-4251-ba51-cbc862d6c5a9@googlegroups.com> |
| In reply to | #104597 |
On Friday, February 24, 2017 at 4:25:50 PM UTC, David Brown wrote: > On 24/02/17 16:49, Malcolm McLean wrote: > This is all roughly true. But the big question here - the elephant in > the room - is "so what?". What does it matter that some projects have > big makefiles? Or that some makefiles are hard to comprehend? > Because the issue is often "what if things go wrong?" Often there's some reason a workable executable isn't produced, and often the reason is pretty trivial, like M_PI in a C source file when the symbol isn't available, or the wrong path to the library, or a wrong version of a library specified. But the build system can be so convoluted that it's virtually impossible to find these errors. For example, someone did a study of DNA alignment algorithms. Half of the algorithms were excluded from the analysis because the investigators could not install them. That's makefiles for you.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-02-24 14:28 -0800 |
| Message-ID | <7019bd8a-6b51-466e-9878-009a38d4967e@googlegroups.com> |
| In reply to | #104613 |
On Friday, February 24, 2017 at 12:01:19 PM UTC-6, Malcolm McLean wrote: > On Friday, February 24, 2017 at 4:25:50 PM UTC, David Brown wrote: > > On 24/02/17 16:49, Malcolm McLean wrote: > > > This is all roughly true. But the big question here - the elephant in > > the room - is "so what?". What does it matter that some projects have > > big makefiles? Or that some makefiles are hard to comprehend? > > > Because the issue is often "what if things go wrong?" Then fix it! -- dear henry dear henry dear henry
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-02-24 16:08 +0000 |
| Message-ID | <HTYrA.17433$2F2.7327@fx22.iad> |
| In reply to | #104580 |
BartC <bc@freeuk.com> writes: >On 24/02/2017 14:03, Scott Lurndal wrote: >> BartC <bc@freeuk.com> writes: >>> On 23/02/2017 23:56, GOTHIER Nathan wrote: >>>> On Thu, 23 Feb 2017 20:11:01 +0000 >>>> BartC <bc@freeuk.com> wrote: >>>> >>>>> And real makefiles rapidly get completely incomprehensible. >>>> >>>> Just learn the basic rules, that's not more complicated than writing your own >>>> building script. Once more, make is POSIX compliant which is pretty common to >>>> all Linux and BSD systems. >>>> >>>> http://pubs.opengroup.org/onlinepubs/7908799/xcu/make.html >>> >>> Sorry, it's not for me. But others may benefit if they want to go with >>> the crowd. >>> >>> (BTW why does it need to have such a cryptic syntax? If 30,000-line >>> configure files are in order, then why not spell things out a little >>> more obviously? >>> >>> Also, is the following makefile syntax? Or does it need further >>> processing become a proper makefile? It's part of makefile.in for gmp >>> (the other is makefile.am): >>> >>> # Makefile.in generated by automake 1.11.6 from Makefile.am. >>> # @configure_input@ >> >> This isn't a Makefile, it is an autoconf intermediate file. > >This sort of reinforces my point. That you can't even tell what is or >isn't or makefile. Sure I can. > >Apparently, in this example, the makefile proper doesn't even exist >except as some temporary, transient file. Then no amount of docs are >going to help understanding when things go wrong. (And if you could >pinpoint the place in the temp makefile, that doesn't help because the >actual problem is buried within two or three generations of automatic >scripting.) You may want to do some research on 'autoconf' and get back to us with your preconceptions corrected. The output of autoconf/automake is a Makefile. The inputs aren't. > >Nor it is easy for them to see when the complexity of what they are >doing starts to exceed the complexity of the task: namely, run a >compiler on a bunch of files. You're conflating make(1) with autoconf(1), whose purpose is actually to run a compiler on a bunch of files to support building on a wide range of operating systems[*] supporting a non-intersecting set of programming API's. [*] Wide ranging, from MacOs to VMS. And yes, autoconf & friends while widely used, are very obtuse. One need not use them to use make appropriately.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-24 18:18 +0000 |
| Message-ID | <o8pte6$pk$2@z-news.wcss.wroc.pl> |
| In reply to | #104559 |
BartC <bc@freeuk.com> wrote:
> On 23/02/2017 23:56, GOTHIER Nathan wrote:
> > On Thu, 23 Feb 2017 20:11:01 +0000
> > BartC <bc@freeuk.com> wrote:
> >
> >> And real makefiles rapidly get completely incomprehensible.
> >
> > Just learn the basic rules, that's not more complicated than writing your own
> > building script. Once more, make is POSIX compliant which is pretty common to
> > all Linux and BSD systems.
> >
> > http://pubs.opengroup.org/onlinepubs/7908799/xcu/make.html
>
> Sorry, it's not for me. But others may benefit if they want to go with
> the crowd.
>
> (BTW why does it need to have such a cryptic syntax? If 30,000-line
> configure files are in order, then why not spell things out a little
> more obviously?
>
> Also, is the following makefile syntax? Or does it need further
> processing become a proper makefile? It's part of makefile.in for gmp
> (the other is makefile.am):
>
> # Makefile.in generated by automake 1.11.6 from Makefile.am.
> # @configure_input@
Do you have problem with reading comprehension? It clearly
says 'Makefile.in' which is skeleton that will be mangled
by configure to produce real Makefile.
> There are, mercifully, only 1400 lines of this stuff (but 29770 lines of
> configure scripts). I don't think anyone can say this is anything other
> than gobbledygook. At least, it makes gcc header files look marvellously
> clear in comparison!)
Well, 'autotools' are messy. But fact that automatically
generated Makefile is messy does not mean that all Makefiles
have to be messy. In fact, for a simple project one can
have tiny Makefile which IMO is more readable than instructions
written in English. If you look at BSD makefiles at first
they may look complicated but if you get the light you will
see that they follow quite understandble pattern.
And they concisely specify a lot of things.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-02-25 15:37 +0000 |
| Message-ID | <slrnob396i.1411.grahn+nntp@frailea.sa.invalid> |
| In reply to | #104518 |
On Thu, 2017-02-23, BartC wrote: > On 23/02/2017 19:03, Jorgen Grahn wrote: >> On Wed, 2017-02-22, BartC wrote: >>> On 22/02/2017 09:09, David Brown wrote: >>>> On 21/02/17 22:31, BartC wrote: >> ... >>>> People use "make" because it is very convenient, does an excellent job, >> ... >>>> and once you have learned the basics, it is easier than most >>>> alternatives. People have used it for 30 years and still use it, >>>> because it is a /good/ tool. >>> >>> No, a good tool is this: >>> >>> "compile .c modules A, B and C >>> then link them" >> >> CFLAGS=-W -Wall -pedantic -ansi -g -Os >> >> foo: A.o >> foo: B.o >> foo: C.o >> $(CC) $(CFLAGS) -o $@ $< >> >> That's a more complete instruction -- human-readable /and/ it's >> executable by make. > > I'll have to take your word that $@ and $< are human readable. Sorry, my claim should have been more like "my makefile is at least as useful as a manual instruction, as yours". > $(CC) I assume is some variable set up to refer to the C compiler in > use. Correct -- either the default one, or one of the user's choice. Then you move over to $(CFLAGS): > But this seems to assume gcc-compatible options; what if someone > wants to use a different compiler with a different option scheme? Then they'll have to set other flags. Still, I think it's better for them that I show the gcc options, so they at least know which C dialect the code is in. > And real makefiles rapidly get completely incomprehensible. Here I finally get to grind *my* axe ... IMO far too many Makefiles are slow, incomprehensible and/or broken. I don't know why it's so -- they don't *have* to be. If I don't need cross-compilation (I never do) and don't aim to support a dozen platforms I have never personally used, and don't need configure-style selection of features, my Makefiles always end up clear, brief and correct. And it's not because I'm unusually smart. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-21 10:56 -0800 |
| Message-ID | <lnmvdfl6ew.fsf@kst-u.example.com> |
| In reply to | #104317 |
supercat@casperkitty.com writes:
[...]
> Otherwise, gcc4 is fairly "modern". Do you know where I could find the
> documentation for versions in the 1989-1996 era?
The documentation is included in the gcc sources, which can be cloned
from git://gcc.gnu.org/git/gcc.git . The history goes back to 1988.
--
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-02-27 05:18 -0600 |
| Message-ID | <t9mdnSdlmLqLlinFnZ2dnUU7-YvNnZ2d@supernews.com> |
| In reply to | #104304 |
supercat@casperkitty.com wrote:
> On Monday, February 20, 2017 at 5:15:14 PM UTC-6, Keith Thompson wrote:
>> I don't know. The history of gcc is publicly available.
>
> I've not found information about gcc versions prior to about 1997.
> It seems that development split because one group was too
> conservative, while another wanted to add things like "New alias
> analysis support from John F. Carr".
It wasn't really about conservatism, it's that GCC development had
stalled because there was only one GCC maintainer, Richard Kenner. He
didn't have the time to keep up with everything that needed to be
done. (As was said at the time, "Kenner does not scale.") All of the
GCC developers moved to EGCS, which had a much more open development
model.
> I would be genuinely interested in knowing whether that fork
> represents the first time that anyone involved with gcc gave serious
> thought to the notion that a quality compiler given something like:
>
> void force_float_negative(float *f1)
> {
> *(unsigned long*)f1 |= 0x80000000;
> }
>
> should optimize on the presumption that such a function won't actually be
> used to access something of the passed-in pointer type. I can't find any
> substantive information about previous versions or the documentation
> therefor, however.
I think it's a coincidence that this was done around the EGCS time
frame, although it's possible that it couldn't have been done
otherwise becase GCC development was stalled. Mark Mitchell wrote a
piece in Dr Dobb's
http://www.drdobbs.com/cpp/type-based-alias-analysis/184404273 but
that was after the fact.
As for giving "serious thought", I don't remember it being
particularly controversial. We knew that GCC's alias analysis was
weak, and the lack of it inhibited optimization. (Note that GCC
already had alias analysis, but it wasn't very thorough.) In the
1990s several academic papers covered efficient alias analysis for C,
and John Carr's contribution was a significant improvement.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-27 08:46 -0800 |
| Message-ID | <3c762130-8395-45f8-bd74-18ffa98b007c@googlegroups.com> |
| In reply to | #104838 |
On Monday, February 27, 2017 at 5:19:10 AM UTC-6, Andrew Haley wrote:
> supercat wrote:
> > On Monday, February 20, 2017 at 5:15:14 PM UTC-6, Keith Thompson wrote:
> >> I don't know. The history of gcc is publicly available.
> >
> > I've not found information about gcc versions prior to about 1997.
> > It seems that development split because one group was too
> > conservative, while another wanted to add things like "New alias
> > analysis support from John F. Carr".
>
> It wasn't really about conservatism, it's that GCC development had
> stalled because there was only one GCC maintainer, Richard Kenner. He
> didn't have the time to keep up with everything that needed to be
> done. (As was said at the time, "Kenner does not scale.") All of the
> GCC developers moved to EGCS, which had a much more open development
> model.
The term "conservative" was present in the history I read. If I read
you correctly, that term wasn't really accurate: the problem wasn't
an ideological desire to preserve positive aspects of the status quo,
but simply a lack of manpower to do much of anything. Would that be
a fair assessment?
> > I would be genuinely interested in knowing whether that fork
> > represents the first time that anyone involved with gcc gave serious
> > thought to the notion that a quality compiler given something like:
> >
> > void force_float_negative(float *f1)
> > {
> > *(unsigned long*)f1 |= 0x80000000;
> > }
> >
> > should optimize on the presumption that such a function won't actually be
> > used to access something of the passed-in pointer type. I can't find any
> > substantive information about previous versions or the documentation
> > therefor, however.
>
> I think it's a coincidence that this was done around the EGCS time
> frame, although it's possible that it couldn't have been done
> otherwise becase GCC development was stalled.
If it brought in people with different ideologies, the fact that the
project started being driven by a different ideology would hardly be
coincidence.
> Mark Mitchell wrote a
> piece in Dr Dobb's
> http://www.drdobbs.com/cpp/type-based-alias-analysis/184404273 but
> that was after the fact.
That article sounds interesting. I'll have to read it more later.
> As for giving "serious thought", I don't remember it being
> particularly controversial. We knew that GCC's alias analysis was
> weak, and the lack of it inhibited optimization. (Note that GCC
> already had alias analysis, but it wasn't very thorough.) In the
> 1990s several academic papers covered efficient alias analysis for C,
> and John Carr's contribution was a significant improvement.
Many aliasing optimizations are be just fine when compiler writers
recognize a few things that would likely have been considered common
sense in 1989:
1. C was/is used for many purposes whose needs are not always
compatible. The Standard does not try to forbid all behaviors
that would make a compiler unsuitable for any particular purpose
(or, as acknowledged in the rationale for the One Program Rule,
for any purpose whatsoever). Thus, the fact that the Standard
would "allow" an optimization does not imply that an implementation
can apply it without making
2. Even in fields like systems programming, type-based aliasing can
be a good thing if limited to cases where a compiler would--**even
without the rule**--have no *particular* reason to expect cross-type
aliasing. More aggressive assumptions which would be appropriate in
compilers targeting some fields (high-end number crunching) would
be grossly inappropriate in others, but as long as compiler writers
exercise judgment appropriate to the compiler's intended purpose,
and programmers recognize that compiler writers may do so, there
should be few problems, even in code which relies upon features
beyond those guaranteed by the Standard.
3. If compiler X can support optimizations which are compatible with
most code intended for some purpose, and version Y only supports
more aggressive optimizations which would break such code, the
optimization "enhancements" in version Y will make it less efficient
at processing such code than version X was.
The authors of gcc seem to have completely lost sight of all three
principles.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-02-27 11:26 -0600 |
| Message-ID | <3IKdnU56gPHH_CnFnZ2dnUU7-afNnZ2d@supernews.com> |
| In reply to | #104890 |
supercat@casperkitty.com wrote: > On Monday, February 27, 2017 at 5:19:10 AM UTC-6, Andrew Haley wrote: >> supercat wrote: >> > On Monday, February 20, 2017 at 5:15:14 PM UTC-6, Keith Thompson wrote: >> >> I don't know. The history of gcc is publicly available. >> > >> > I've not found information about gcc versions prior to about 1997. >> > It seems that development split because one group was too >> > conservative, while another wanted to add things like "New alias >> > analysis support from John F. Carr". >> >> It wasn't really about conservatism, it's that GCC development had >> stalled because there was only one GCC maintainer, Richard Kenner. He >> didn't have the time to keep up with everything that needed to be >> done. (As was said at the time, "Kenner does not scale.") All of the >> GCC developers moved to EGCS, which had a much more open development >> model. > > The term "conservative" was present in the history I read. If I read > you correctly, that term wasn't really accurate: the problem wasn't > an ideological desire to preserve positive aspects of the status quo, > but simply a lack of manpower to do much of anything. Would that be > a fair assessment? I believe so, although I think it's fair to say that the people at Cygnus who pushed for EGCS were perhaps more enthusiastic to get more changes done. [Full disclosure: I was at Cygnus.] In particular, Cygnus had a bunch of target machines which weren't your typical 32-bit "All the world's a VAX" designs, and this inevitably was disruptive to the code base. The broadening of GCC's range of targets meant that people without weird hardware couldn't test many changes to GCC, which made life difficult. It led to a distributed development model in which one maintainer didn't have to test everything: each target had its own maintainer who approved patches, who by definition could test them. >> I think it's a coincidence that this was done around the EGCS time >> frame, although it's possible that it couldn't have been done >> otherwise because GCC development was stalled. > > If it brought in people with different ideologies, the fact that the > project started being driven by a different ideology would hardly be > coincidence. No, it wasn't a matter of ideology, and in any case the group of people working on GCC didn't change very much: what changed was the organizational model. >> As for giving "serious thought", I don't remember it being >> particularly controversial. We knew that GCC's alias analysis was >> weak, and the lack of it inhibited optimization. (Note that GCC >> already had alias analysis, but it wasn't very thorough.) In the >> 1990s several academic papers covered efficient alias analysis for C, >> and John Carr's contribution was a significant improvement. > > Many aliasing optimizations are be just fine when compiler writers > recognize a few things that would likely have been considered common > sense in 1989: > > 1. C was/is used for many purposes whose needs are not always > compatible. The Standard does not try to forbid all behaviors > that would make a compiler unsuitable for any particular purpose > (or, as acknowledged in the rationale for the One Program Rule, > for any purpose whatsoever). Thus, the fact that the Standard > would "allow" an optimization does not imply that an implementation > can apply it without making ... a thing? > 2. Even in fields like systems programming, type-based aliasing can > be a good thing if limited to cases where a compiler would--**even > without the rule**--have no *particular* reason to expect cross-type > aliasing. A compiler is just a computer program, and it doesn't know what to expect. It has no way to know what kind of application it is compiling, and I'd personally rather it didn't guess. > More aggressive assumptions which would be appropriate in > compilers targeting some fields (high-end number crunching) > would be grossly inappropriate in others, GCC didn't target any particular fields: it was the compiler for GNU, but was used for many other things too. > but as long as compiler writers exercise judgment appropriate > to the compiler's intended purpose, and programmers recognize > that compiler writers may do so, there should be few problems, > even in code which relies upon features beyond those > guaranteed by the Standard. Sure, see below. > 3. If compiler X can support optimizations which are compatible with > most code intended for some purpose, and version Y only supports > more aggressive optimizations which would break such code, the > optimization "enhancements" in version Y will make it less efficient > at processing such code than version X was. > > The authors of gcc seem to have completely lost sight of all three > principles. I don't think that's true of GCC, really. Everybody knew that there were programs which accessed data in ways which went beyond those guaranteed by the standard, so a command-line option to turn type-based alias analysis off was provided at the time. There were also old programs that nobody wanted to change, and their users would need compiler options to keep things going for a while. But at the time a pressing need was to try to make the performance of C competitive with FORTRAN, and it's hard to do that in a world where everything aliases with everything else. Also, getting good performance from compiled C++ was very important, and again accurate alias information helps a lot. The default was (and stil is) the standard language plus some GCC extensions. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-27 13:57 -0800 |
| Message-ID | <e45c3039-8c40-4028-86cb-90c068b1c301@googlegroups.com> |
| In reply to | #104897 |
On Monday, February 27, 2017 at 11:27:02 AM UTC-6, Andrew Haley wrote: > supercat wrote: > I believe so, although I think it's fair to say that the people at > Cygnus who pushed for EGCS were perhaps more enthusiastic to get more > changes done. [Full disclosure: I was at Cygnus.] In particular, > Cygnus had a bunch of target machines which weren't your typical > 32-bit "All the world's a VAX" designs, and this inevitably was > disruptive to the code base. The broadening of GCC's range of targets > meant that people without weird hardware couldn't test many changes to > GCC, which made life difficult. It led to a distributed development > model in which one maintainer didn't have to test everything: each > target had its own maintainer who approved patches, who by definition > could test them. Thanks for the historical perspective. I can see that trying to port C to "interesting" platforms could affect one's perspective. As someone who has used C on some unusual platforms myself, I can appreciate that not all the world's a VAX, but at the same time I see little value in trying to make code work on obscure architectures *except in those cases where it is likely to be used on them*. If the authors of the C Standard want to encourage programmers to write code that should work on all platforms, they should define platform-independent ways of specifying things like structure layouts. If a program specified that "foo.x" should be a 32-bit unsigned value encoded as four octets (individually zero-padded) in big-endian order, starting at offset 6, attempts to access such a member might be inefficient on things other than 16-bit big-endian machines, but code could be written to run correctly on all machines without having to sacrifice performance on 16-bit big-endian machines. > >> As for giving "serious thought", I don't remember it being > >> particularly controversial. We knew that GCC's alias analysis was > >> weak, and the lack of it inhibited optimization. (Note that GCC > >> already had alias analysis, but it wasn't very thorough.) In the > >> 1990s several academic papers covered efficient alias analysis for C, > >> and John Carr's contribution was a significant improvement. > > > > Many aliasing optimizations are be just fine when compiler writers > > recognize a few things that would likely have been considered common > > sense in 1989: > > > > 1. C was/is used for many purposes whose needs are not always > > compatible. The Standard does not try to forbid all behaviors > > that would make a compiler unsuitable for any particular purpose > > (or, as acknowledged in the rationale for the One Program Rule, > > for any purpose whatsoever). Thus, the fact that the Standard > > would "allow" an optimization does not imply that an implementation > > can apply it without making > > ... a thing? Sorry--I meant to say that the fact that the Standard would "allow" an optimization does not imply that applying it would not make an implementation grossly unsuitable for some purposes. > > 2. Even in fields like systems programming, type-based aliasing can > > be a good thing if limited to cases where a compiler would--**even > > without the rule**--have no *particular* reason to expect cross-type > > aliasing. > > A compiler is just a computer program, and it doesn't know what to > expect. It has no way to know what kind of application it is > compiling, and I'd personally rather it didn't guess. Some compilers are specialized for particular purposes, such as high-end number crunching. If a compiler is intended for a variety of purposes, it should avoid any behaviors that would make it grossly unsuitable for any of them. While "expecting" may have been slightly anthropomorphic, I'm not calling for anything overly sophisticated. Most aliasing optimizations generally involve a compiler seeing an access to an object in execution sequence and a place where it would be more useful to perform the access, and also seeing that there are no potentially-conflicting accesses between them. While 100% accurately recognizing all other accesses as conflicting or non- conflicting would be essentially impossible, it would not be hard to define rules which support the semantics necessary to for system programming while still allowing the majority of useful optimizations. As a simple example, regard an access A using a pointer of type U as being a potential access to object O of type T, if a pointer conversion involving type T* and a conversion involving type U* have both appeared since the most recent one of the following: - An access of type O using type T - The start of an enclosing function - The start of an enclosing loop, if any Such rules would forbid a few optimizations that might otherwise be usable, but most places where such optimizations would be useful would not have any "conflicting" casts nearby. More sophisticated rules could allow compilers to benefit from aliasing assumptions in a few more cases [e.g. look at how the results of pointer casts are used] but I'm not sure how often the extra optimizations would justify the effort. What's significant is that a compiler that applied such rules could be compatible with a very large fraction of programs that would otherwise require -fno-strict-aliasing, while allowing many more optimizations than would be possible using that flag. > > More aggressive assumptions which would be appropriate in > > compilers targeting some fields (high-end number crunching) > > would be grossly inappropriate in others, > > GCC didn't target any particular fields: it was the compiler for GNU, > but was used for many other things too. A general-purpose compiler should avoid behaviors that would be grossly inappropriate for any common uses, *except when programmers explicitly invite such behaviors*. Of course, there's no reason that a compiler's optional modes would need to be limited to optimizations allowed by the Standard. A lot of code, for example, could be optimized more effectively, without adversely affecting correctness, if character types weren't treated as special but applied the rules I listed above as applicable to other types. > > but as long as compiler writers exercise judgment appropriate > > to the compiler's intended purpose, and programmers recognize > > that compiler writers may do so, there should be few problems, > > even in code which relies upon features beyond those > > guaranteed by the Standard. > > Sure, see below. > > > 3. If compiler X can support optimizations which are compatible with > > most code intended for some purpose, and version Y only supports > > more aggressive optimizations which would break such code, the > > optimization "enhancements" in version Y will make it less efficient > > at processing such code than version X was. > > > > The authors of gcc seem to have completely lost sight of all three > > principles. > > I don't think that's true of GCC, really. Everybody knew that there > were programs which accessed data in ways which went beyond those > guaranteed by the standard, so a command-line option to turn > type-based alias analysis off was provided at the time. There were > also old programs that nobody wanted to change, and their users would > need compiler options to keep things going for a while. But at the > time a pressing need was to try to make the performance of C > competitive with FORTRAN, and it's hard to do that in a world where > everything aliases with everything else. Also, getting good > performance from compiled C++ was very important, and again accurate > alias information helps a lot. In many cases, the "old programs" need semantics for which the Standard makes no provision. If the Standard were to specify ways of expressing such semantics, then code which relies upon implicit support for such semantics might sensibly be deprecated. As far as I can tell, however, the Standard has made no effort to define any way by which the necessary semantics can be efficiently expressed, even though no implementation should have trouble offering the necessary guarantees. Further, reread my #3: if many programs would be just fine with 85% of the optimizations of a particular type, and it would be easy to distinguish most of the non-problematic ones from those those which are or might be problematic. > The default was (and stil is) the standard language plus some GCC > extensions. There never has been a single "standard language" that was suitable for purposes like embeddded or systems programming. Further, even when used in C89 mode, gcc applies "optimizations" which have no justification within the text of the C89 Standard.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-27 14:06 -0800 |
| Message-ID | <e0130ce5-f52a-4885-a407-0a1f869ecc27@googlegroups.com> |
| In reply to | #104943 |
On Monday, February 27, 2017 at 3:57:33 PM UTC-6, supe...@casperkitty.com wrote: > As a simple example, regard an access A using a pointer of type U as being > a potential access to object O of type T, if a pointer conversion involving > type T* and a conversion involving type U* have both appeared since the > most recent one of the following: > > - An access of type O using type T > - The start of an enclosing function > - The start of an enclosing loop, if any On the last two of the above, I should have said "the start of an enclosing function wherein O is accessed by an lvalue of type T which is not a result of a typecast within the function", and likewise with loop. Basically, allow accesses to be hoisted to the start of a function or loop, or to the point of the previous access, and also allow them to be moved forward by smaller amounts in cases where they could be moved forward to one of the above.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-02-28 04:25 -0600 |
| Message-ID | <s8ydnTlAhKG5zSjFnZ2dnUU7-f_NnZ2d@supernews.com> |
| In reply to | #104943 |
supercat@casperkitty.com wrote: > On Monday, February 27, 2017 at 11:27:02 AM UTC-6, Andrew Haley wrote: >> supercat wrote: >> I believe so, although I think it's fair to say that the people at >> Cygnus who pushed for EGCS were perhaps more enthusiastic to get more >> changes done. [Full disclosure: I was at Cygnus.] In particular, >> Cygnus had a bunch of target machines which weren't your typical >> 32-bit "All the world's a VAX" designs, and this inevitably was >> disruptive to the code base. The broadening of GCC's range of targets >> meant that people without weird hardware couldn't test many changes to >> GCC, which made life difficult. It led to a distributed development >> model in which one maintainer didn't have to test everything: each >> target had its own maintainer who approved patches, who by definition >> could test them. > > Thanks for the historical perspective. I can see that trying to > port C to "interesting" platforms could affect one's perspective. > As someone who has used C on some unusual platforms myself, I can > appreciate that not all the world's a VAX, but at the same time I > see little value in trying to make code work on obscure > architectures *except in those cases where it is likely to be used > on them*. I should have been clear: this was for money. Cygnus didn't do anything for fun. These ports were used by real customers with real implementations. > What's significant is that a compiler that applied such rules could > be compatible with a very large fraction of programs that would > otherwise require -fno-strict-aliasing, while allowing many more > optimizations than would be possible using that flag. Have you actually tried doing this? You'd have to define in a precise and unambiguous way what types of memory might alias, and you'd have to gain sufficient support from C users for your semantics to justify changing GCC. I don't particularly like the idea of an alias analysis phase littered with "if (supercat_aliasing)" conditional statements. >> The default was (and stil is) the standard language plus some GCC >> extensions. > > There never has been a single "standard language" that was suitable > for purposes like embeddded or systems programming. Further, even > when used in C89 mode, gcc applies "optimizations" which have no > justification within the text of the C89 Standard. Have these been reported? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-28 15:45 -0800 |
| Message-ID | <c4a4babe-62dd-4a35-b146-f6c088981b02@googlegroups.com> |
| In reply to | #105072 |
On Tuesday, February 28, 2017 at 4:25:54 AM UTC-6, Andrew Haley wrote:
> supercat wrote:
> > Thanks for the historical perspective. I can see that trying to
> > port C to "interesting" platforms could affect one's perspective.
> > As someone who has used C on some unusual platforms myself, I can
> > appreciate that not all the world's a VAX, but at the same time I
> > see little value in trying to make code work on obscure
> > architectures *except in those cases where it is likely to be used
> > on them*.
>
> I should have been clear: this was for money. Cygnus didn't do
> anything for fun. These ports were used by real customers with real
> implementations.
Indeed. If one has to accomplish some purpose with an obscure machine, like
writing a TCP stack for a DSP with a 16-bit "char", one writes code that
targets that machine. I doubt I'll ever use another platform where my TCP
stack would be at all useful, since all its logic is designed to work with
chunks that hold two octets each. It might be adaptable to kinda work on
on other platforms, whether bit-endian or little-endian, since I used an
application typedef everywhere I needed a 16-bit chunk, but on more
conventional architectures the code which uses individual octets would
have been more efficient if it could have used an octet type rather than
having to use packing and unpacking functions all the time.
Still, I do not begrudge the fact that TCP code for conventional machines
won't work on that DSP, nor that my TCP code for that DSP won't really be
useful on other machines, even though it could probably be adapted to work
on many of them with aliasing disabled (since uint16_t would no longer be
the "character type"). Being able to use C syntax with that weird
architecture was a lot more convenient than assembly language would have
been, even though the semantics were sometimes a bit unusual.
> > What's significant is that a compiler that applied such rules could
> > be compatible with a very large fraction of programs that would
> > otherwise require -fno-strict-aliasing, while allowing many more
> > optimizations than would be possible using that flag.
>
> Have you actually tried doing this?
>
> You'd have to define in a precise and unambiguous way what types of
> memory might alias, and you'd have to gain sufficient support from C
> users for your semantics to justify changing GCC. I don't
> particularly like the idea of an alias analysis phase littered with
> "if (supercat_aliasing)" conditional statements.
If the compiler optimized the ways that compilers were doing when I took
my graduate-level compiler course it wouldn't be hard, and one could
still end up with much better optimizations than with -fno-strict-aliasing.
The more complex forms of optimization would make things a bit harder,
but hardly unreasonable if one can tolerate missing an occasional
optimization here and there.
From a programmer's side, the rule would be that if aliasing rules would
regard an object as being accessible as type T, and a pointer to that object
is converted to U, the object will be readable as type U via the resulting
pointer or pointers derived therefrom until the next time one of the
following happens:
1. The object is written using a type other than U via means other than
a pointer derived from the result of the cast.
2. Execution enters a function wherein a write like #1 occurs.
3. Execution enters a loop wherein a write like #1 occurs.
and will be writable as type U via the resulting pointer or pointers
derived therefrom until one of the following happens:
1. The object is accessed via means other than a pointer derived from
the result of the cast.
2. Execution enters a function wherein an access like #1 occurs.
3. Execution enters a loop wherein an access like #1 occurs.
Treatment of void* should be configurable, based upon whether one wishes
to maximize compatibiltiy with existing -fno-strict-aliasing code, or
whether one merely wishes to support all the semantics required by
such code. I'd suggest as "preferred" semantics that implicit conversions
involving void* would only be allowed if the storage was, for aliasing
purposes, already accessible as the other type. Explicit conversions to
void* would create a temporary window to access the storage of any type
until it's accessed via unrelated means, while explicit conversions from
void* would behave as conversions from the original type, if known, or
from any arbitrary type.
Reads of storage with conflicting writes would behave as though the
storage held arbitrary bit patterns. Writes that conflict with other
writes would behave as though subsequent reads of the storage yield
arbitrary bit patterns unless or until there is a non-conflicting
write.
Add in another rule which would allow "volatile void**" to access a pointer
of any type that shares a representation with void* (and likewise volatile
void*** to access double-indirect pointers, etc.), allow int32_t* to
access any 32-bit integer type with which it is representation-compatible,
etc. and a lot of code which would presently require -fno-strict-aliasing
would be usable without it.
Note that this rule allows optimizations that C99's Effective Type rule would
not. For example, given:
float test(int ia[], float fa[])
{
float total = 0.0f;
for (int i=0; i<100; i++)
total += fa[i];
for (int i=0; i<100; i++)
ia[i] = i;
}
the C99 rules would require that all reads of fa occur before any writes
to ia, since writes to ia[] would set the effective type of the storage to
int. By contrast, if a programmer waived C99/C11 rules, my rules would
allow the compiler to assume that "ia" and "fa" wouldn't alias at all
and thus overlap operations using them in arbitrary fashion.
From an implementation perspective, one could easily achieve a significant
fraction of the optimizations allowed by aliasing if accesses are always
either performed in order, consolidated with preceding or succeeding
accesses, or hoisted to the start of a loop or function. Simply treat
any conversion from a pointer to one type to some another type as a
potential access to an object of the pointer's original type. Explicit
conversions involving void* should be treated as potential accesses to
all objects. That would be slightly more pessimistic than necessary,
but would still allow many useful optimizations to be performed easily.
Optimizations that would behave as though accesses were rearranged in
other ways would have to check before moving an access forward in time
whether it could be moved all the way to the previous access, start
of the current loop, or start of the current function; if the access
could be moved all the way to one of those points without crossing
any conflicting type conversion, behavior equivalent to moving by a
lesser amount would also be allowable.
For many kinds of code, the largest number of needless barriers would
arise in cases where a pointer is converted to void* and then back to
its own type. In cases where a compiler could see that the result of
such a conversion will be used for no purpose but conversion back to
its original type, the conversion to void* would not need to be treated
as a barrier.
While the aforementioned implementation would make aliasing assumptions
that were slightly more pesimistic than necessary, I doubt that such
assumptions would have a significant adverse impact on the performance
of most code, since pointer conversions aren't used much outside code
which needs to exploit aliasing. If additional patterns are found
where the pesimistic assumptions have a significant detrimental effect
on performance, most of those could be resolved with tracing logic
that might have been considered complex in 1990s standards, but not
by today's.
The only cases I see as problematical are those involving void*, which
would invovle trade-offs between compatbility and optimization. Requiring
at least one explicit type conversion in situations involving type
punning would make it necessary to add some explicit casts to existing
-fno-strict-aliasing code to make it compatible with the aliasing rules,
but would limit the semantics available to the programmer.
> >> The default was (and stil is) the standard language plus some GCC
> >> extensions.
> >
> > There never has been a single "standard language" that was suitable
> > for purposes like embeddded or systems programming. Further, even
> > when used in C89 mode, gcc applies "optimizations" which have no
> > justification within the text of the C89 Standard.
>
> Have these been reported?
Sure. The authors of gcc claim that C89 allows gcc to ignore the CIS
in cases like the following:
struct s1 {int x;};
struct s2 {int x;};
union u { struct s1 v1; struct s2 v2; };
int test(struct s1 *p1, struct s2 *p2)
{
p1->x = 1;
p2->x = 2;
return p1->x;
}
Nothing in C89 suggests that the Common Initial Sequence rule should
not be applicable here. C99 can kinda sorta be contorted to suggest
that it shouldn't apply but I see nothing in C89 that would even
remotely suggest that the CIS wouldn't apply. The authors of gcc
regard with derision the idea that the mere existence of the union
should be sufficient to render the CIS applicable, but I would suggest
that most programmers don't define union types with arbitrary
combinations of structures for no reason. Alarmist claims that
acknowledging the CIS in such cases would totally destroy any hope
of useful optimization are vastly overblown.
In the event that some code needs to declare a union type but doesn't
need CIS guarantees applied to the structures therein, compilers could
offer an attribute to specify that CIS handling was not required.
Using directives to enable rather than block optimziation would mean
that code could be made compatible with compilers that don't understand
the directives by using macros which can expand to such directives or
to nothing, depending upon the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-01 03:46 -0600 |
| Message-ID | <kaidnfGhmYXEBSvFnZ2dnUU7-VvNnZ2d@supernews.com> |
| In reply to | #105185 |
supercat@casperkitty.com wrote:
> On Tuesday, February 28, 2017 at 4:25:54 AM UTC-6, Andrew Haley wrote:
>> supercat wrote:
>
>> > What's significant is that a compiler that applied such rules could
>> > be compatible with a very large fraction of programs that would
>> > otherwise require -fno-strict-aliasing, while allowing many more
>> > optimizations than would be possible using that flag.
>>
>> Have you actually tried doing this?
>>
>> You'd have to define in a precise and unambiguous way what types of
>> memory might alias, and you'd have to gain sufficient support from C
>> users for your semantics to justify changing GCC. I don't
>> particularly like the idea of an alias analysis phase littered with
>> "if (supercat_aliasing)" conditional statements.
>
> If the compiler optimized the ways that compilers were doing when I
> took my graduate-level compiler course it wouldn't be hard, and one
> could still end up with much better optimizations than with
> -fno-strict-aliasing. The more complex forms of optimization would
> make things a bit harder, but hardly unreasonable if one can
> tolerate missing an occasional optimization here and there.
>
> From a programmer's side, the rule would be that if aliasing rules
> would regard an object as being accessible as type T, and a pointer
> to that object is converted to U, the object will be readable as
> type U via the resulting pointer or pointers derived therefrom until
> the next time one of the following happens:
>
> 1. The object is written using a type other than U via means other than
> a pointer derived from the result of the cast.
>
> 2. Execution enters a function wherein a write like #1 occurs.
>
> 3. Execution enters a loop wherein a write like #1 occurs.
>
> and will be writable as type U via the resulting pointer or pointers
> derived therefrom until one of the following happens:
>
> 1. The object is accessed via means other than a pointer derived from
> the result of the cast.
>
> 2. Execution enters a function wherein an access like #1 occurs.
>
> 3. Execution enters a loop wherein an access like #1 occurs.
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.
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.
> The only cases I see as problematical are those involving void*,
> which would invovle trade-offs between compatbility and
> optimization. Requiring at least one explicit type conversion in
> situations involving type punning would make it necessary to add
> some explicit casts to existing -fno-strict-aliasing code to make it
> compatible with the aliasing rules, but would limit the semantics
> available to the programmer.
So what's stopping you from implementing this scheme? You say it's
not difficult to do, but there's no subsititute for working code.
Then you could run a bunch of benchmarks and measure the performance
change. You'd have something real to talk about.
You've obviously thought about this for some time, and have considered
the costs and benefits. So do it.
>> >> The default was (and stil is) the standard language plus some GCC
>> >> extensions.
>> >
>> > There never has been a single "standard language" that was suitable
>> > for purposes like embeddded or systems programming. Further, even
>> > when used in C89 mode, gcc applies "optimizations" which have no
>> > justification within the text of the C89 Standard.
>>
>> Have these been reported?
>
> Sure. The authors of gcc claim ...
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.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 06:30 -0800 |
| Message-ID | <ac146a38-61ad-4444-911e-2ac4a80b0451@googlegroups.com> |
| In reply to | #105225 |
On Wednesday, March 1, 2017 at 3:46:15 AM UTC-6, Andrew Haley wrote:
> supercat wrote:
> > From a programmer's side, the rule would be that if aliasing rules
> > would regard an object as being accessible as type T, and a pointer
> > to that object is converted to U, the object will be readable as
> > type U via the resulting pointer or pointers derived therefrom until
> > the next time one of the following happens:
> >
> > 1. The object is written using a type other than U via means other than
> > a pointer derived from the result of the cast.
> >
> > 2. Execution enters a function wherein a write like #1 occurs.
> >
> > 3. Execution enters a loop wherein a write like #1 occurs.
> >
> > and will be writable as type U via the resulting pointer or pointers
> > derived therefrom until one of the following happens:
> >
> > 1. The object is accessed via means other than a pointer derived from
> > the result of the cast.
> >
> > 2. Execution enters a function wherein an access like #1 occurs.
> >
> > 3. Execution enters a loop wherein an access like #1 occurs.
>
> 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.
In cases where a compiler is able to observe in more detail how the results
of casts are used, it may be able to minimize the effect on optimization,
but data flow analysis would not be required to maintain correctness. As
a simple example:
uint32_t float_as_bits(float *f)
{
uint32_t *p = (uint32_t*)f;
return *p;
}
A compiler could treat the cast as a read-write barrier for type "float"
(forcing all float pending writes to occur before it, and preventing any
acceleration of accesses between that conversion and the next access not
made through *p or the next hoist point). Slightly more sophisticated
analysis would allow a compiler to recognize that only a read barrier is
required since it can see all accesses performed using *p, and none of
them involve writing.
A compiler can't move an access unless it can see that there are no conflicting
accesses between them. The only time my rule would require a compiler to see
anything beyond that would be in cases where a compiler might want to perform
an access early, but not move it as far as the nearest "hoist point" (other
access to the same object, or the start of the enclosing function or loop,
whichever happens last). In those cases, a compiler would have to see that
there was no conflicting cast between the proposed new location and the
preceding hoist point, but a compiler should have no trouble seeing that code
since it was *just looking at it*.
For example, given:
uint32_t float_as_bits(float *f1, float *f2)
{
float result;
uint32_t *p = (uint32_t*)f;
result= *p;
*f2 = 2.0;
return result;
}
a compiler that wanted to accelerate the store to f2 would have to observe
whether there had any casts involving float since the start of the nearest
enclosing loop or function, whichever happened last. Since there are no
loops, it would look back to the start of the function and observe that the
it would not be able to move the write of f2 that far without crossing a
type conversion of a "float*" which could alias it.
> 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. In that case, if g were
something like:
void g(double *b)
{
*(long*)b = 0x12345678;
}
a compiler would have to mark it as writing unknown objects of types "long"
and "double". If nothing about "g" suggested that it did anything with
objects of type "long", a compiler processing "f" could perform the access
to "a" before calling g. Nothing about my rules would affect the required
logic for processing "f", since if g() had been:
void g(double *b)
{
extern long l;
l = 0x12345678;
}
a compiler would not be allowed to move that above the read of *a under any
kind of C rules.
> > The only cases I see as problematical are those involving void*,
> > which would invovle trade-offs between compatbility and
> > optimization. Requiring at least one explicit type conversion in
> > situations involving type punning would make it necessary to add
> > some explicit casts to existing -fno-strict-aliasing code to make it
> > compatible with the aliasing rules, but would limit the semantics
> > available to the programmer.
>
> So what's stopping you from implementing this scheme? You say it's
> not difficult to do, but there's no subsititute 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 suppose a simple hack of gcc would be an option to treat all pointer type
conversions as inserting a dummy asm directive. That would kill a lot of
optimizations, of course, but not nearly as many as -fno-strict-aliasing.
I'm also not sure that would necessarily prevent gcc from trying to move
accesses forward by an amount smaller than the next hoist point.
> > Sure. The authors of gcc claim ...
>
> 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.
If code has a number of structures like:
struct shape {
void *typeInfo;
ui16 datasize;
}
struct alignedrectangle {
void *typeInfo;
ui16 datasize;
ui16 color,left,top,right,bottom;
}
struct triangle {
void *typeInfo;
ui16 datasize;
ui16 color,x1,y1,x2,y2,x3,y3;
}
struct shape_group_start {
void *typeInfo;
ui16 datasize;
char name[];
}
and expects to be able to cast a pointer to any such structure to a
"struct shape*" and have that function work with its common members, how
could that be accommodated without using -fno-strict-aliasing or other
gcc-specific options? Such techniques were certainly allowable in C89
and I'd hardly call them obsolete. Note that if pointers require 32-bit
alignment, the size of the common prefix would not be a multiple of that,
so requiring that each shape start with a "header" object would not be an
option if the layout is defined as part of the API.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-01 16:31 +0100 |
| Message-ID | <o96pcu$d9s$1@dont-email.me> |
| In reply to | #105250 |
On 01/03/17 15:30, supercat@casperkitty.com wrote: > On Wednesday, March 1, 2017 at 3:46:15 AM UTC-6, Andrew Haley wrote: >> >> 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. No, it is not. The most common standard for embedded programming is C99, and has been for a good many years. The only compilers that are limited to C89 typically have significant non-standard elements, and that are usually programmed in a very target-specific manner (such as the 16-bit char DSP you mentioned earlier). There are some code bases that are in C89 (usually called "ANSI C") - that is common for things like portable RTOS's or network stacks. But the compilers support newer standards, and it is very common to use at least some C99 features (like mixing declarations and statements). It is /not/ common to see that knowingly relies on features of C89 that are not compatible with C99. And the single most common compiler used for embedded programming these days is gcc for ARM Cortex M devices - almost always with a version that is new enough to support the "-std=gnu11" or "-std=c11" flags, though not necessarily new enough to support all of C11.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 08:37 -0800 |
| Message-ID | <22a3c409-e39b-4f55-94bb-6a478317659a@googlegroups.com> |
| In reply to | #105255 |
On Wednesday, March 1, 2017 at 9:31:39 AM UTC-6, David Brown wrote:
> No, it is not. The most common standard for embedded programming is
> C99, and has been for a good many years. The only compilers that are
> limited to C89 typically have significant non-standard elements, and
> that are usually programmed in a very target-specific manner (such as
> the 16-bit char DSP you mentioned earlier).
Many compilers have over time added most C99 features (things like //
comments are pretty much universal), but the "attitude" is one of C89
plus C99 features. I haven't seen commercial embedded compilers seeking
to regard as undefined any behaviors that had been defined in C89.
> There are some code bases that are in C89 (usually called "ANSI C") -
> that is common for things like portable RTOS's or network stacks.
>
> But the compilers support newer standards, and it is very common to use
> at least some C99 features (like mixing declarations and statements).
> It is /not/ common to see that knowingly relies on features of C89 that
> are not compatible with C99.
The memory manager included in a typical RTOS will allow for storage to be
used as one type, and then recycled for use as another type, initially
holding Unspecified Value of that latter type, without requiring that the
storage be overwritten between uses in cases where the later user doesn't
care about the bit patterns contained therein. Any memory manager which
provides such semantics without scrubbing storage *must* rely upon
guarantees beyond those given in C99 or C11 because those versions of the
language define Effective Type semantics which would cause any read of
storage using a type other than the one used to write it as yielding
Undefined Behavior rather than an Unspecified Value.
Under C89, given:
union { int i; float f; } u;
int *ip = &u.i; float *fp = &u.f;
Writing u.f and reading u.i would yield an Unspecified Value, except on
implementations where "int" could have trap representations, and nothing
in C89 would indicate that the semantics of writing *fp and reading *ip
would not match those of accessing struct members directly. The guarantee
that writing as one type and reading as a type with no trap representations
would at worst yield an Unspecified Value is essential to facilitate
efficient memory managers. C89 provided that guarantee; C99 and C11 do not.
Because C is used for many purposes which do not require the ability to
handle efficient mixed-type memory pools in user code, the C99 and C11
Standards do not require implementations to provide everything needed for
such pools to be implemented in user code. Any application requiring the
implementation of such pools in user code will thus require guarantees beyond
those given in C99 or C11.
> And the single most common compiler used for embedded programming these
> days is gcc for ARM Cortex M devices - almost always with a version that
> is new enough to support the "-std=gnu11" or "-std=c11" flags, though
> not necessarily new enough to support all of C11.
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-01 19:02 +0100 |
| Message-ID | <o9728u$f91$1@dont-email.me> |
| In reply to | #105268 |
On 01/03/17 17:37, supercat@casperkitty.com wrote:
> On Wednesday, March 1, 2017 at 9:31:39 AM UTC-6, David Brown wrote:
>> No, it is not. The most common standard for embedded programming is
>> C99, and has been for a good many years. The only compilers that are
>> limited to C89 typically have significant non-standard elements, and
>> that are usually programmed in a very target-specific manner (such as
>> the 16-bit char DSP you mentioned earlier).
>
> Many compilers have over time added most C99 features (things like //
> comments are pretty much universal), but the "attitude" is one of C89
> plus C99 features. I haven't seen commercial embedded compilers seeking
> to regard as undefined any behaviors that had been defined in C89.
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.
Also remember that a good many people pay money for gcc - it is open
source, but is also sold as commercial open source along with
guarantees, support, Plum Hall certification, etc.
>
>> There are some code bases that are in C89 (usually called "ANSI C") -
>> that is common for things like portable RTOS's or network stacks.
>>
>> But the compilers support newer standards, and it is very common to use
>> at least some C99 features (like mixing declarations and statements).
>> It is /not/ common to see that knowingly relies on features of C89 that
>> are not compatible with C99.
>
> The memory manager included in a typical RTOS will allow for storage to be
> used as one type, and then recycled for use as another type, initially
> holding Unspecified Value of that latter type, without requiring that the
> storage be overwritten between uses in cases where the later user doesn't
> care about the bit patterns contained therein. Any memory manager which
> provides such semantics without scrubbing storage *must* rely upon
> guarantees beyond those given in C99 or C11 because those versions of the
> language define Effective Type semantics which would cause any read of
> storage using a type other than the one used to write it as yielding
> Undefined Behavior rather than an Unspecified Value.
Okay... typically such code works but is dependent on the implementation
(it is very likely to work on any sane implementation on a cpu with a
limited number of registers).
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?
Note that in practice, such code is regularly compiled in C99 (or C11)
mode on modern compilers.
>
> Under C89, given:
>
> union { int i; float f; } u;
> int *ip = &u.i; float *fp = &u.f;
>
> Writing u.f and reading u.i would yield an Unspecified Value, except on
> implementations where "int" could have trap representations, and nothing
> in C89 would indicate that the semantics of writing *fp and reading *ip
> would not match those of accessing struct members directly.
In 6.3.2.3 of C89, it says "if a member of a union object is accessed
after a value has been stored in a different member of the object, the
behavior is implementation-defined"
Not unspecified, and certainly no implication is given that it should
work like accessing struct members. C99 changed that, defining "type
punning" access through unions.
> The guarantee
> that writing as one type and reading as a type with no trap representations
> would at worst yield an Unspecified Value is essential to facilitate
> efficient memory managers. C89 provided that guarantee; C99 and C11 do not.
Nope - neither through unions nor through pointer casts, as far as I can
see in C89, C99 and C11 standards. You have to use character access,
memcpy or memmove. C99 and C11 at least let you do it using unions.
(Of course implementations can give you more guarantees here.)
> Because C is used for many purposes which do not require the ability to
> handle efficient mixed-type memory pools in user code, the C99 and C11
> Standards do not require implementations to provide everything needed for
> such pools to be implemented in user code. Any application requiring the
> implementation of such pools in user code will thus require guarantees beyond
> those given in C99 or C11.
That makes no sense. The inability to make general memory pools (or
implement malloc) relying purely on standard C, is not because C is
sometimes used for other purposes.
>
>> And the single most common compiler used for embedded programming these
>> days is gcc for ARM Cortex M devices - almost always with a version that
>> is new enough to support the "-std=gnu11" or "-std=c11" flags, though
>> not necessarily new enough to support all of C11.
>
> 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. You can then make
other copies of it to different pointer types - the space only gets an
effective type when you first write to it. With C89, the type is taken
from the first pointer assigned to the return value of the malloc()
call. Basically, C99 just formalised and clarified how this works - it
was not really a change. It did not even get a mention in the C99
rationale - if the change were as big as you seem to imagine, it would
have warranted an entry in the rationale.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 10:49 -0800 |
| Message-ID | <cbad74ba-d708-4e54-a364-93f55a787106@googlegroups.com> |
| In reply to | #105291 |
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. If writing one type and reading another results in
the *behavior* being implementation-defined rather than just the *value*,
that would allow implementations even under C89 to specify aliasing behaviors
which would make them useless for systems programming, but such behavioral
limitations would need to be documented as such.
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.
> > The memory manager included in a typical RTOS will allow for storage to be
> > used as one type, and then recycled for use as another type, initially
> > holding Unspecified Value of that latter type, without requiring that the
> > storage be overwritten between uses in cases where the later user doesn't
> > care about the bit patterns contained therein. Any memory manager which
> > provides such semantics without scrubbing storage *must* rely upon
> > guarantees beyond those given in C99 or C11 because those versions of the
> > language define Effective Type semantics which would cause any read of
> > storage using a type other than the one used to write it as yielding
> > Undefined Behavior rather than an Unspecified Value.
>
> Okay... typically such code works but is dependent on the implementation
> (it is very likely to work on any sane implementation on a cpu with a
> limited number of registers).
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?
> But why do you think C89 is any different here?
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).
> In 6.3.2.3 of C89, it says "if a member of a union object is accessed
> after a value has been stored in a different member of the object, the
> behavior is implementation-defined"
>
> Not unspecified, and certainly no implication is given that it should
> work like accessing struct members. C99 changed that, defining "type
> punning" access through unions.
Does anything in C99 distinguish between the use of pointers to access union
members, versus accessing them directly?
> > The guarantee
> > that writing as one type and reading as a type with no trap representations
> > would at worst yield an Unspecified Value is essential to facilitate
> > efficient memory managers. C89 provided that guarantee; C99 and C11 do not.
>
> Nope - neither through unions nor through pointer casts, as far as I can
> see in C89, C99 and C11 standards. You have to use character access,
> memcpy or memmove. C99 and C11 at least let you do it using unions.
I wasn't requiring that the value read have any relation to the value
written, but was requiring that nasal demons not be launched even when
using storage with no effective type.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-01 21:00 +0100 |
| Message-ID | <o97961$agt$1@dont-email.me> |
| In reply to | #105298 |
On 01/03/17 19:49, supercat@casperkitty.com wrote:
> 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. If writing one type and reading another results in
> the *behavior* being implementation-defined rather than just the *value*,
> that would allow implementations even under C89 to specify aliasing behaviors
> which would make them useless for systems programming, but such behavioral
> limitations would need to be documented as such.
>
> 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;
}
This is a perfectly allowed transformation under C89, as far as I
interpret the standard.
I believe you are making the argument:
1. Compilers in the days of C89 were not smart enough to do type-based
alias optimisations.
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).
3. Therefore, C89 allowed code that is broken by today's optimising
compilers and/or the C99 standard.
It is step 3 that you have got wrong.
>
>>> The memory manager included in a typical RTOS will allow for storage to be
>>> used as one type, and then recycled for use as another type, initially
>>> holding Unspecified Value of that latter type, without requiring that the
>>> storage be overwritten between uses in cases where the later user doesn't
>>> care about the bit patterns contained therein. Any memory manager which
>>> provides such semantics without scrubbing storage *must* rely upon
>>> guarantees beyond those given in C99 or C11 because those versions of the
>>> language define Effective Type semantics which would cause any read of
>>> storage using a type other than the one used to write it as yielding
>>> Undefined Behavior rather than an Unspecified Value.
>>
>> Okay... typically such code works but is dependent on the implementation
>> (it is very likely to work on any sane implementation on a cpu with a
>> limited number of registers).
>
> 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?
>
>> But why do you think C89 is any different here?
>
> 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 6.3.2.3 of C89, it says "if a member of a union object is accessed
>> after a value has been stored in a different member of the object, the
>> behavior is implementation-defined"
>>
>> Not unspecified, and certainly no implication is given that it should
>> work like accessing struct members. C99 changed that, defining "type
>> punning" access through unions.
>
> Does anything in C99 distinguish between the use of pointers to access union
> members, versus accessing them directly?
>
>>> The guarantee
>>> that writing as one type and reading as a type with no trap representations
>>> would at worst yield an Unspecified Value is essential to facilitate
>>> efficient memory managers. C89 provided that guarantee; C99 and C11 do not.
>>
>> Nope - neither through unions nor through pointer casts, as far as I can
>> see in C89, C99 and C11 standards. You have to use character access,
>> memcpy or memmove. C99 and C11 at least let you do it using unions.
>
> I wasn't requiring that the value read have any relation to the value
> written, but was requiring that nasal demons not be launched even when
> using storage with no effective type.
>
[toc] | [prev] | [next] | [standalone]
Page 9 of 27 — ← Prev page 1 … 7 8 [9] 10 11 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web