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 4 of 27 — ← Prev page 1 2 3 [4] 5 6 … 27 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-21 09:28 +0100 |
| Message-ID | <o8gtj4$j8t$1@dont-email.me> |
| In reply to | #104304 |
On 21/02/17 01:19, 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. > Look at the current extensions page: <https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html> Look at the matching page from an old version: <https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html> I doubt if anyone else cares about which extensions in gcc use reserved identifiers, and which do not - so you can do your own homework here if you are interested. /Most/ newer gcc extensions are handled using __attribute__ or __builtin , which are reserved identifiers. But not everything is done that way. And even when reserved identifiers are used, programs that use these are not going to be valid programs on any other compiler, making the distinction pretty much irrelevant. The reason that gcc uses "__attribute__" rather than "attribute" is so that standard C code can compile correctly with gcc, not so that "gcc C" code that uses __attribute__ can work on other compilers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-21 09:19 -0800 |
| Message-ID | <9a61886f-1f50-4b4c-a088-6e378cba9f68@googlegroups.com> |
| In reply to | #104308 |
On Tuesday, February 21, 2017 at 2:28:12 AM UTC-6, David Brown wrote: > Look at the current extensions page: > > <https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html> > > Look at the matching page from an old version: > > <https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html> Looking through the list, I don't see any reference in the gcc4 documentation to binary literals, hex floats, or unnamed struct/union members. I know those had been in supported in a number of compilers for a really long time, but I don't know when gcc got them. Most of the features in the newer list that aren't in the old list use reserved names. Otherwise, gcc4 is fairly "modern". Do you know where I could find the documentation for versions in the 1989-1996 era?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-21 19:21 +0100 |
| Message-ID | <o8i0ci$dsu$1@dont-email.me> |
| In reply to | #104317 |
On 21/02/17 18:19, supercat@casperkitty.com wrote: > On Tuesday, February 21, 2017 at 2:28:12 AM UTC-6, David Brown wrote: >> Look at the current extensions page: >> >> <https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html> >> >> Look at the matching page from an old version: >> >> <https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html> > > Looking through the list, I don't see any reference in the gcc4 documentation > to binary literals, hex floats, or unnamed struct/union members. I know > those had been in supported in a number of compilers for a really long time, > but I don't know when gcc got them. Most of the features in the newer list > that aren't in the old list use reserved names. > > Otherwise, gcc4 is fairly "modern". Do you know where I could find the > documentation for versions in the 1989-1996 era? > I didn't link to gcc 4 documentation - I linked to section 4 of the gcc 2.95.3 documentation, which is from 2001. That is the oldest version with the manual conveniently online in the same place as modern manuals. The first beta release of gcc, version 0.9 from 1987, is available with a little effort - Bart will be impressed with its 502 KB download size. I have no idea of the state of the documentation at that time. <ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/old-releases/gcc-1/> <https://gcc.gnu.org/releases.html> Beyond that, you can do your homework yourself.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-21 19:21 +0000 |
| Message-ID | <o8i3sr$rc9$1@dont-email.me> |
| In reply to | #104325 |
On 21/02/2017 18:21, David Brown wrote: > The first beta release of gcc, version 0.9 from 1987, is available with > a little effort - Bart will be impressed with its 502 KB download size. I've just downloaded it. About 100 files in all with 44 .c files. I tried to compile one, and it said: "expr.c:22:20: fatal error: config.h: No such file or directory" FFS! Even in 1987 they seemed to have been at it. (And if you try and by-pass config.h, then there are yet more non-existent headers. Even using 'make' on Linux complains about the missing file.) But it probably wouldn't have worked very well as it seemed to target 68K or VAX. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-21 21:34 +0100 |
| Message-ID | <o8i84j$br7$1@dont-email.me> |
| In reply to | #104331 |
On 21/02/17 20:21, BartC wrote: > On 21/02/2017 18:21, David Brown wrote: > >> The first beta release of gcc, version 0.9 from 1987, is available with >> a little effort - Bart will be impressed with its 502 KB download size. > > I've just downloaded it. About 100 files in all with 44 .c files. > > I tried to compile one, and it said: > > "expr.c:22:20: fatal error: config.h: No such file or directory" > > FFS! Even in 1987 they seemed to have been at it. (And if you try and > by-pass config.h, then there are yet more non-existent headers. Even > using 'make' on Linux complains about the missing file.) > > But it probably wouldn't have worked very well as it seemed to target > 68K or VAX. > I assume it's fair to say you did not read the documentation or attempt to follow the instructions? Like the README file, that refers to the internals.dvi (helpfully this document is pre-generated in the tarball, to save you installing texinfo software). It is likely that there will be issues trying to compile this code on a modern system - it is pre-C90, before C was properly standardised, and will conflict with the default settings of a modern compiler. It is also likely that it will conflict with the library headers of a modern system - you may need to find an old C library to compile it as it is not designed to compile on a modern Linux or Windows host. And at best you'd end up with a cross-compiler for the m68k or VAX. The whole point of the exercise was to show Supercat a bit of gcc history. Release 0.9 is a bit /too/ old - there is no documentation about extensions that I could find, and since it is a beta version from before the ANSI C standardisation, that is not surprising.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-21 21:31 +0000 |
| Message-ID | <o8ibfv$nvc$1@dont-email.me> |
| In reply to | #104334 |
On 21/02/2017 20:34, David Brown wrote: > On 21/02/17 20:21, BartC wrote: >> On 21/02/2017 18:21, David Brown wrote: >> >>> The first beta release of gcc, version 0.9 from 1987, is available with >>> a little effort - Bart will be impressed with its 502 KB download size. >> >> I've just downloaded it. About 100 files in all with 44 .c files. >> >> I tried to compile one, and it said: >> >> "expr.c:22:20: fatal error: config.h: No such file or directory" >> >> FFS! Even in 1987 they seemed to have been at it. (And if you try and >> by-pass config.h, then there are yet more non-existent headers. Even >> using 'make' on Linux complains about the missing file.) >> >> But it probably wouldn't have worked very well as it seemed to target >> 68K or VAX. >> > > I assume it's fair to say you did not read the documentation or attempt > to follow the instructions? Like the README file, that refers to the > internals.dvi (helpfully this document is pre-generated in the tarball, > to save you installing texinfo software). I glanced at the README, but the first thing I did was to grab a C file at random and to try and compile it. And that failed because there is no config.h. If I look into internals.texinfo, that says that config.h should be a symbolic link to another config*.h; I'd been about to just copy one over, but it also needed insn-codes.h and insn-flags.h. It says these are generated by gencodes.c and genflags.c. OK, I'll compile those and run them. But genflags.c needs objstack.h, and there is no file called objstack.h, and there is no mention of it in internals.texinfo. > It is likely that there will be issues trying to compile this code on a > modern system - it is pre-C90, before C was properly standardised, and > will conflict with the default settings of a modern compiler. It is > also likely that it will conflict with the library headers of a modern > system - you may need to find an old C library to compile it as it is > not designed to compile on a modern Linux or Windows host. And at best > you'd end up with a cross-compiler for the m68k or VAX. > > The whole point of the exercise was to show Supercat a bit of gcc > history. Release 0.9 is a bit /too/ old - there is no documentation > about extensions that I could find, and since it is a beta version from > before the ANSI C standardisation, that is not surprising. I just wanted ANY C project to compile that wasn't 100% dependent on a 'configure' script and a make-file. But as I as said in a recent, Linux programmers seem to be incapable on doing something so straightforward, even 30 years ago. I bet even a Hello World from them would need a make-file! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-22 10:09 +0100 |
| Message-ID | <o8jkd3$r3m$1@dont-email.me> |
| In reply to | #104336 |
On 21/02/17 22:31, BartC wrote: > On 21/02/2017 20:34, David Brown wrote: >> On 21/02/17 20:21, BartC wrote: >>> On 21/02/2017 18:21, David Brown wrote: >>> >>>> The first beta release of gcc, version 0.9 from 1987, is available >>>> with >>>> a little effort - Bart will be impressed with its 502 KB download size. >>> >>> I've just downloaded it. About 100 files in all with 44 .c files. >>> >>> I tried to compile one, and it said: >>> >>> "expr.c:22:20: fatal error: config.h: No such file or directory" >>> >>> FFS! Even in 1987 they seemed to have been at it. (And if you try and >>> by-pass config.h, then there are yet more non-existent headers. Even >>> using 'make' on Linux complains about the missing file.) >>> >>> But it probably wouldn't have worked very well as it seemed to target >>> 68K or VAX. >>> >> >> I assume it's fair to say you did not read the documentation or attempt >> to follow the instructions? Like the README file, that refers to the >> internals.dvi (helpfully this document is pre-generated in the tarball, >> to save you installing texinfo software). > > I glanced at the README, but the first thing I did was to grab a C file > at random and to try and compile it. And that failed because there is no > config.h. I /read/ the relevant section in the README (it was rather short), and then the relevant section of internals.dvi (also short). I made the symbolic links requested, and ran "make" as directed. There were a few issues with the compilation of "gcc.c" - some of the system header files have more modern function declarations (with "const" and stuff) that conflicted with the old ones in the file, but that was easily dealt with. The binaries would not link, however, due to differences in the libraries - I guess from the error messages that the problem lies in thread support. I expect that a bit of fiddling with the compiler flags in the makefile, to make modern gcc act a little more like an old compiler, would get it working. But that's more effort than a want to put into this. However, I did this using a host and tools that are a lot more compatible with the systems supported by this old compiler, rather than trying to do it on Windows. And I don't have your perverse allergy to following instructions or using standard tools like "make". > > If I look into internals.texinfo, that says that config.h should be a > symbolic link to another config*.h; I'd been about to just copy one > over, but it also needed insn-codes.h and insn-flags.h. It says these > are generated by gencodes.c and genflags.c. > > OK, I'll compile those and run them. But genflags.c needs objstack.h, > and there is no file called objstack.h, and there is no mention of it in > internals.texinfo. > >> It is likely that there will be issues trying to compile this code on a >> modern system - it is pre-C90, before C was properly standardised, and >> will conflict with the default settings of a modern compiler. It is >> also likely that it will conflict with the library headers of a modern >> system - you may need to find an old C library to compile it as it is >> not designed to compile on a modern Linux or Windows host. And at best >> you'd end up with a cross-compiler for the m68k or VAX. >> >> The whole point of the exercise was to show Supercat a bit of gcc >> history. Release 0.9 is a bit /too/ old - there is no documentation >> about extensions that I could find, and since it is a beta version from >> before the ANSI C standardisation, that is not surprising. > > I just wanted ANY C project to compile that wasn't 100% dependent on a > 'configure' script and a make-file. But as I as said in a recent, Linux > programmers seem to be incapable on doing something so straightforward, > even 30 years ago. I bet even a Hello World from them would need a > make-file! > 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. Alternatives have come and gone - make remains a key tool in most developers toolboxes. Kind of like "C". And "configure" scripts have been used to solve a challenge for a lot of software - how to make it compile and run on dozens of different OS's, dozens of different target processors, and hundreds and thousands of variations of installed libraries, compiler versions, and so on. The also provide a standardised way to customise the building and installation of the software. Yes, configure scripts can be daunting if you look at them - but most people don't look at them. They just run them as the instructions say. They might feel that the configure stage is a little inefficient, but it works. Remember, your little toy compiler is built to run on a single host OS and single host processor, compiling for that same single target OS and target processor, and you will compile it using a set of a few known compilers. gcc supports compilation on dozens of different OS's, dozens of processor types, dozens of variations for each processor. The compiled binaries can run on a /different/ system entirely, and they generate code for yet a third /different/ system. It can be compiled using a wide range of different compilers, it supports half a dozen different programming languages and a score of human languages, as well as a vast array of configuration options. "./configure" handles all this rather neatly.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-22 10:43 +0100 |
| Message-ID | <20170222104334.bde2c154e6f6a554ce9a3f95@gmail.com> |
| In reply to | #104356 |
On Wed, 22 Feb 2017 10:09:40 +0100 David Brown <david.brown@hesbynett.no> 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. Alternatives have come and gone - make > remains a key tool in most developers toolboxes. Kind of like "C". It's not easier or more handy to write make files than building scripts. The first goal of the make tool is to build uptodate targets with a set of rules. > And "configure" scripts have been used to solve a challenge for a lot of > software - how to make it compile and run on dozens of different OS's, > dozens of different target processors, and hundreds and thousands of > variations of installed libraries, compiler versions, and so on. The > also provide a standardised way to customise the building and > installation of the software. Yes, configure scripts can be daunting if > you look at them - but most people don't look at them. They just run > them as the instructions say. They might feel that the configure stage > is a little inefficient, but it works. That's the main problem with configure scripts. Most of their promoters don't want to understand them and rely on Autotools like some web designers are unable to understand any snippet of HTML code using WYSIWYG tools. Autotools are unsuitable to write reliable configure scripts abusing of intermediate make files. Even the use of a make files to install/uninstall is abusive. Actually, portable softwares should only be POSIX compliant with exceptions for non standard environments. The portability cost related to non standard environments should be weighted to the return they could generate.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-22 12:43 +0000 |
| Message-ID | <o8k0ui$5nb$1@dont-email.me> |
| In reply to | #104356 |
On 22/02/2017 09:09, David Brown wrote: > On 21/02/17 22:31, BartC wrote: >> I glanced at the README, but the first thing I did was to grab a C file >> at random and to try and compile it. And that failed because there is no >> config.h. > > I /read/ the relevant section in the README (it was rather short), and > then the relevant section of internals.dvi (also short). I made the > symbolic links requested, and ran "make" as directed. What did you do about the missing 'objstack.h' that is needed for compiling 'gencode.c' that needs to be linked and run to generate insn-code.h that is needed to compile expr.c? > There were a few > issues with the compilation of "gcc.c" - some of the system header files > have more modern function declarations (with "const" and stuff) that > conflicted with the old ones in the file, but that was easily dealt > with. > However, I did this using a host and tools that are a lot more > compatible with the systems supported by this old compiler, rather than > trying to do it on Windows. It's C source code. The language hasn't changed that much, has it? And there's always such a big hoo-hah about making the slightest change in the language that would break compatibility with existing code. Now you seem to be saying that that backwards compatibility doesn't really exist anyway? > And I don't have your perverse allergy to > following instructions or using standard tools like "make". The instructions (which are difficult to read in .lexinfo format and even my Ubuntu couldn't read .div) talks about creating links. I don't know how to do that so I used 'cp' (this is in Linux). 'make' now runs but gives errors in gcc.c; it doesn't get as far as expr.c or gencode.c >> I just wanted ANY C project to compile that wasn't 100% dependent on a >> 'configure' script and a make-file. But as I as said in a recent, Linux >> programmers seem to be incapable on doing something so straightforward, >> even 30 years ago. I bet even a Hello World from them would need a >> make-file! >> > > People use "make" because it is very convenient, does an excellent job, If I type 'make' in Windows, it gives me: "make: Line too long near line 218" Truly excellent. (Line 218 is a 64-character comment, but no newline. If I add a newline, then I get: 'Unknown option: /g.') > 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" Don't forget that for such a task as this - doing a one-time build of something that has already been developed - you don't need incremental builds or anything fancy. You just want the whole lot compiled. > Alternatives have come and gone - make > remains a key tool in most developers toolboxes. Kind of like "C". Provided it's not an old version... > And "configure" scripts have been used to solve a challenge for a lot of > software - how to make it compile and run on dozens of different OS's, > dozens of different target processors, and hundreds and thousands of > variations of installed libraries, compiler versions, and so on. The > also provide a standardised way to customise the building and > installation of the software. That's great. Except most people are only interested in a tiny number of targets, and perhaps only one. Yes, configure scripts can be daunting if > you look at them - but most people don't look at them. They just run > them as the instructions say. They might feel that the configure stage > is a little inefficient, but it works. Building GMP required a configure script of either 20,000 or 30,000 lines; I forget which. A 'little inefficient' is putting it mildly. But it is completely over the top. GMP isn't that big. And I wanted GMP as a library for a small part of my language system which itself totalled only 20,000 lines. Yet the script to configure a tiny part of an application prior to compiling that small part, is bigger than the entire application! > Remember, your little toy compiler is built to run on a single host OS > and single host processor, compiling for that same single target OS and > target processor, Yes, a bit like the little toy compiler called gcc-0.9 (OK, that has two targets!) The real reason I wanted to build this is so that I could use it as test input for my own compiler. But it needs to work with existing C compilers first. So forget that project. But then most C apps that originate in Linux seem exactly the same. They are not C apps at all, they are mostly bash and makefile apps; the C code is incidental! and you will compile it using a set of a few known > compilers. I doubt whether you will compile your own apps with anything other than gcc... gcc supports compilation on dozens of different OS's, dozens > of processor types, dozens of variations for each processor. But apparently it has some trouble compiling C code of 30 years ago. The > compiled binaries can run on a /different/ system entirely, and they > generate code for yet a third /different/ system. It can be compiled > using a wide range of different compilers, it supports half a dozen > different programming languages and a score of human languages, as well > as a vast array of configuration options. "./configure" handles all > this rather neatly. Neatly? Whatever the project happens to be, configure scripts all seem to have tens of thousands of lines! All full of complete and utter crap (if you don't believe me, take a look). If a script fails at line 17931 out of 31625, how the hell is anyone supposed to figure out how to fix it? And which configure file? The latest gcc source contains 35 'configure' scripts totalling over half a million lines. The largest single script is 84,000 lines. And this is code that is largely written sideways with lots of junk crammed onto each line. I'm not interested in grappling with scripting code (especially when you go to a lot of trouble downloading all the right tools to make it work on Windows, and then it doesn't work.). I just want to compile an application that is /supposedly/ written in C. That would normally be challenging enough by itself. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-22 15:07 +0000 |
| Message-ID | <87y3wy6z7e.fsf@bsb.me.uk> |
| In reply to | #104362 |
BartC <bc@freeuk.com> writes: > On 22/02/2017 09:09, David Brown wrote: >> On 21/02/17 22:31, BartC wrote: > >>> I glanced at the README, but the first thing I did was to grab a C file >>> at random and to try and compile it. And that failed because there is no >>> config.h. >> >> I /read/ the relevant section in the README (it was rather short), and >> then the relevant section of internals.dvi (also short). I made the >> symbolic links requested, and ran "make" as directed. > > What did you do about the missing 'objstack.h' that is needed for > compiling 'gencode.c' that needs to be linked and run to generate > insn-code.h that is needed to compile expr.c? Odd. I don't see that at all. make builds genflags but I can't run it (segmentation fault) presumably because of all the int/pointer conversion assumptions. >> There were a few >> issues with the compilation of "gcc.c" - some of the system header files >> have more modern function declarations (with "const" and stuff) that >> conflicted with the old ones in the file, but that was easily dealt >> with. > >> However, I did this using a host and tools that are a lot more >> compatible with the systems supported by this old compiler, rather than >> trying to do it on Windows. > > It's C source code. The language hasn't changed that much, has it? Yes, it has. Prototypes, void, const and a whole raft of other small changes. The code does use void (and the compiler is prepared to compile code that uses const despite not using it itself) but not in the most useful way (it's almost always just a void return type). It's essentially K&R C with a few voids thrown in to indicate no return value from a function. For example, the first hard error I get is that sys_errlist is declared in gcc.c (presumably one could not rely on it being declared in a header) but the modern header declaration has an incompatible type since because it uses const. But, more importantly, the C culture has changed since C90 first permitted relative portable code to be written. This example uses int returns as pointers all over the place and makes all sorts of other non-portable assumptions. It hedges it's bets by declaring things that don't need to be declared now and might, like the example above, have an incompatible declaration in ANSI C. And it sometimes avoids declaring lots of other things (malloc, realloc, strcpy and so on) because that avoids the hassle of knowing what file to include (yes, it varied from compiler to compiler) and, presumably because it was often harmless at the time, it assumes an int return will do for pointer-returning functions. That was probably a reasonable trade-off at the time. Nowadays you can rely on stdlib.h and string.h, and there are machines where the int to pointer conversion is lossy (to say the least) so you would probably not make that choice. > And > there's always such a big hoo-hah about making the slightest change in > the language that would break compatibility with existing code. Now > you seem to be saying that that backwards compatibility doesn't really > exist anyway? There are two points here. First, the care about not breaking existing code has been mainly since C90. C90 had to choose between lots of commonly adopted forms, practices and extensions and that probably broke more code (though often in minor ways) than subsequent revisions did. Second, you can only really avoid breaking code that is as robust as possible. Take sys_errlist for example. Had gcc.c not included an old, non-const declaration of it the new one from the system header would probably do fine. But the authors probably felt they had to declare it because it was not declared in a predictably names header file (that's a guess but it was the most common reason at the time for declaring things like that yourself). This code is more open to breakage from standard declarations than some other code from the time. That's not C90's fault. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-22 09:26 -0800 |
| Message-ID | <b7235675-9743-426d-8fff-0d5d349ad5c2@googlegroups.com> |
| In reply to | #104364 |
On Wednesday, February 22, 2017 at 9:07:58 AM UTC-6, Ben Bacarisse wrote:
> But, more importantly, the C culture has changed since C90 first
> permitted relative portable code to be written.
C90 did not "permit" portable code to be written for machines which followed
the pattern established by the PDP-11. There are a few areas where it helped
with portability on such machines, most notably by standardizing the locations
of things within header files and the means by which code accesses variadic
arguments, but the real contemporaneous effect of C90 was to establish what
aspects of PDP-11 behavior needed to be carry across to platforms which were
significantly different (e.g. unsigned types wrap are required to wrap with
a power-of-two modulus even on platforms whose arithmetic instructions wrap
in some other fashion).
The authors of the Standard recognized that:
1. Not all implementations are intended for use with the same kinds
of programs and platforms.
2. Semantic guarantees which would be essential for some kinds of
programs, and could be cheaply upheld on some platforms, may be
very useless but expensive for implementations targeting some
types of applications on some platforms.
3. People writing C implementations were likely in a better position
than people writing standards to exercise good judgment with regard
to the cost-benefit trade-offs associated with semantic guarantees.
When C89 Standard left certain behaviors undefined, that does not mean
that the authors attempted to make any kind of judgment as to whether a
typical implementation should guarantee a behavior, but rather whether
the benefits of guaranteeing the behavior were so enormously huge that
they would outweigh the costs *even when the kinds of code where the
guarantees would offer the least value were run on the platforms where
the guarantees imposed the greatest costs*. Leaving undefined any
behaviors which didn't meet that criterion was intended as an invitation
for implementers to exercise their own cost-benefit judgments, rather
than as an invitation to throw judgment out the window.
Although it took awhile, it finally dawned on my why C lacks constructs to
do things like force a region of storage to contain values that are, at
worst, Unspecified [so that code which is prepared for any value that might
be contained in that storage, e.g.
uint32_t item_index = hashtable[hash];
if (item_index < num_items && item_keys[item_index] == item_key)
... item was found
else
... item was not found
could avoid the need to initialize data structures whose initial contents
would not matter]. Implementations that are intended for fields where such
abilities would be useful generally don't require programmers to do anything
special to treat uninitialized storage as having values that are at worst
Unspecified, and implementations that would treat storage in contrary fashion
are generally only used for programs that don't expect storage to initially
hold Unspecified values.
I think portability would be enhanced by adding constructs like "set storage
to Unspecified value". Implementations which naturally treat storage in
such fashion could implement them as no-ops, while those which would
otherwise optimize aggressively could at worst implement them as fill-
with-zero. Code which used such constructs could thus ensure *corectness*
on all implementations without having to sacrifice efficiency on quality
ones (fill-with-zero would be inefficient, but quality implementations
should be able to manage something better).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-22 16:28 +0100 |
| Message-ID | <o8kajh$9cc$1@dont-email.me> |
| In reply to | #104362 |
On 22/02/17 13:43, BartC wrote: > On 22/02/2017 09:09, David Brown wrote: >> On 21/02/17 22:31, BartC wrote: > >>> I glanced at the README, but the first thing I did was to grab a C file >>> at random and to try and compile it. And that failed because there is no >>> config.h. >> >> I /read/ the relevant section in the README (it was rather short), and >> then the relevant section of internals.dvi (also short). I made the >> symbolic links requested, and ran "make" as directed. > > What did you do about the missing 'objstack.h' that is needed for > compiling 'gencode.c' that needs to be linked and run to generate > insn-code.h that is needed to compile expr.c? I find no reference to "objstack.h" anywhere in the code. I see a reference to "obstack.h" - and a file "obstack.h" in the tarball. > >> There were a few >> issues with the compilation of "gcc.c" - some of the system header files >> have more modern function declarations (with "const" and stuff) that >> conflicted with the old ones in the file, but that was easily dealt >> with. > >> However, I did this using a host and tools that are a lot more >> compatible with the systems supported by this old compiler, rather than >> trying to do it on Windows. > > It's C source code. The language hasn't changed that much, has it? Yes. There are constructs that were valid C at that time, but are no longer valid C. I can't say if any of them are an issue here. There are a few more challenges, and things that need to be fixed. The linking command in the Makefile explicitly asks for crt0.o, which is not used the same way with modern tools (it is included in the implicitly specified static c library). And the yacc file contains bugs that older versions of bison glossed over, but newer versions fuss about - so I'd probably have to install an older bison version (2.3 or earlier) to get it working. > And > there's always such a big hoo-hah about making the slightest change in > the language that would break compatibility with existing code. Now you > seem to be saying that that backwards compatibility doesn't really exist > anyway? Backwards compatibility gets a great deal of emphasis with new C standards, but there are sometimes incompatible changes. But that is a matter of the C /language/. There can be many more incompatible changes to any given implementation. There can also be differences in the libraries, the tools command lines, and other tools. It looks to me that the problems lie there rather than in the C code itself. > >> And I don't have your perverse allergy to >> following instructions or using standard tools like "make". > > The instructions (which are difficult to read in .lexinfo format and > even my Ubuntu couldn't read .div) Google a bit - though I recommend looking for a "dvi" viewer rather than a "div" viewer. It is not unlikely that you'll have to install at least some bits of a TeX package to get it working (and be prepared for this to mean /lots/ of files - a full TeXlive installation is /very/ big). Try xdvi if you can't get evince to work. > talks about creating links. I don't > know how to do that so I used 'cp' (this is in Linux). Links are created with the "ln" command. Soft (symbolic) links are with "ln -s config-m68000.h config.h" > 'make' now runs > but gives errors in gcc.c; it doesn't get as far as expr.c or gencode.c That's the linker options - I expect the error you see is that it cannot find crt0.o. Try: gcc -o gcc gcc.o -lg obstack.o -lc and then carry on with the "make". But be prepared to fail at "bison -v parse.y". > >>> I just wanted ANY C project to compile that wasn't 100% dependent on a >>> 'configure' script and a make-file. But as I as said in a recent, Linux >>> programmers seem to be incapable on doing something so straightforward, >>> even 30 years ago. I bet even a Hello World from them would need a >>> make-file! >>> >> >> People use "make" because it is very convenient, does an excellent job, > > If I type 'make' in Windows, it gives me: > > "make: Line too long near line 218" > > Truly excellent. (Line 218 is a 64-character comment, but no newline. If > I add a newline, then I get: 'Unknown option: /g.') Given your abilities with installing tools on Windows, I assume you have got some weird version of make on your path. > >> 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" That's fine for toy programs. Complicated programs need more than that. The build process for gcc includes generating some of the C files using bison (a version of yacc). > > Don't forget that for such a task as this - doing a one-time build of > something that has already been developed - you don't need incremental > builds or anything fancy. You just want the whole lot compiled. > >> Alternatives have come and gone - make >> remains a key tool in most developers toolboxes. Kind of like "C". > > Provided it's not an old version... > >> And "configure" scripts have been used to solve a challenge for a lot of >> software - how to make it compile and run on dozens of different OS's, >> dozens of different target processors, and hundreds and thousands of >> variations of installed libraries, compiler versions, and so on. The >> also provide a standardised way to customise the building and >> installation of the software. > > That's great. Except most people are only interested in a tiny number of > targets, and perhaps only one. Except for all those people interested in all sorts of different versions and combinations. Admittedly the range of host OS's and host processors is a good deal less now that in used to be - few people are running systems other than Linux, BSD, Windows, and Solaris. On the other hand, the range of target processors, and the number of people using gcc for different target processors, has gone up dramatically. > > Yes, configure scripts can be daunting if >> you look at them - but most people don't look at them. They just run >> them as the instructions say. They might feel that the configure stage >> is a little inefficient, but it works. > > Building GMP required a configure script of either 20,000 or 30,000 > lines; I forget which. A 'little inefficient' is putting it mildly. But > it is completely over the top. I thought you said that didn't matter for a build that you don't often do? > > GMP isn't that big. And I wanted GMP as a library for a small part of my > language system which itself totalled only 20,000 lines. Yet the script > to configure a tiny part of an application prior to compiling that small > part, is bigger than the entire application! > >> Remember, your little toy compiler is built to run on a single host OS >> and single host processor, compiling for that same single target OS and >> target processor, > > Yes, a bit like the little toy compiler called gcc-0.9 (OK, that has two > targets!) Supporting two targets is a huge step up from supporting one target. > The real reason I wanted to build this is so that I could use > it as test input for my own compiler. But it needs to work with existing > C compilers first. So forget that project. No sane person would use the initial beta release of gcc for that purpose. I posted the link as the earliest publicly available archive of gcc - not as a tool anyone would want to use. > > But then most C apps that originate in Linux seem exactly the same. They > are not C apps at all, they are mostly bash and makefile apps; the C > code is incidental! > > and you will compile it using a set of a few known >> compilers. > > I doubt whether you will compile your own apps with anything other than > gcc... My own programs are always built with a single explicitly specified version of gcc (or occasionally another compiler) and libraries, with a specific set of compiler flags, all written in the Makefile and with the tools archived with the project. I have little interest in making my programs work with different compilers or different processors - I have a lot of interest in being able to build bit-perfect identical copies of the program whenever I need, on whatever system I need. (Source code may be shared amongst projects, of course, but the build is fixed for each project.) But I write a different sort of program for a different kind of use. > > gcc supports compilation on dozens of different OS's, dozens >> of processor types, dozens of variations for each processor. > > But apparently it has some trouble compiling C code of 30 years ago. Certainly there is code that was valid 30 years ago that is invalid now. "const = 4; foo(const);" was valid in pre-ANSI C. "long = 2; short = 3; bar(long, short);" was valid in old enough C. Feel free to find more examples yourself. > > The >> compiled binaries can run on a /different/ system entirely, and they >> generate code for yet a third /different/ system. It can be compiled >> using a wide range of different compilers, it supports half a dozen >> different programming languages and a score of human languages, as well >> as a vast array of configuration options. "./configure" handles all >> this rather neatly. > > Neatly? Whatever the project happens to be, configure scripts all seem > to have tens of thousands of lines! All full of complete and utter crap > (if you don't believe me, take a look). If a script fails at line 17931 > out of 31625, how the hell is anyone supposed to figure out how to fix it? No one /cares/ how big a configure script is! No one cares what is in it. It is very rare that configure scripts fail, except in /your/ hands - and usually a quick google will find the answer. Just pretend that the configure script is a sort of executable file, not meant to be read any more than an .exe file is meant to be read. > > And which configure file? The latest gcc source contains 35 'configure' > scripts totalling over half a million lines. The largest single script > is 84,000 lines. And this is code that is largely written sideways with > lots of junk crammed onto each line. It is mostly generated automatically - it is not made to be read by people. Which configure file do you run? I'd suggest the "configure" file - being the standard used by vast numbers of software packages, and the one referred to in the installation instructions. > > I'm not interested in grappling with scripting code (especially when you > go to a lot of trouble downloading all the right tools to make it work > on Windows, and then it doesn't work.). Nor am I - but like most people who choose to install something like gcc from source, I am capable of reading and following instructions without having to look at the scripting code. I rarely look at "configure" files - I might do so if I have unusual needs and the software package's documentation is poor. And like most people, I can usually get what I need pre-built. While "./configure && make && make install" is not hard, "apt-get install" is even easier. Windows is a PITA for development and compilation. When I have to use it, I prefer to stick to ready-built packages and let other people find the right tools. But I've built cross-gcc for embedded targets on Windows - I don't have anything like the kind of trouble you seem to get. I believe you have a unique talent for it - you are so convinced that it is hard that you give yourself extra problems. > > I just want to compile an application that is /supposedly/ written in C. > That would normally be challenging enough by itself. >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-22 17:18 +0000 |
| Message-ID | <o8kh11$1vj$1@dont-email.me> |
| In reply to | #104369 |
On 22/02/2017 15:28, David Brown wrote: > On 22/02/17 13:43, BartC wrote: >> What did you do about the missing 'objstack.h' that is needed for >> compiling 'gencode.c' that needs to be linked and run to generate >> insn-code.h that is needed to compile expr.c? > > I find no reference to "objstack.h" anywhere in the code. I see a > reference to "obstack.h" - and a file "obstack.h" in the tarball. OK, that was my mistake: it couldn't find 'obstack.h', but I then searched for 'objstack.h'. The reason it couldn't find it was because it was in <,> brackets, not double quotes. (For some reason, gcc doesn't think of looking in the same directory as the main source code for <,> includes.) I'll have another go. However, if the process depends on 'Make sure the Bison parser generator is installed', then I'm screwed anyway. (I've no idea how to do that, and I expect it I will have its own configure and makefile issues.) THIS is why I'm keen to show how this stuff can be done: One .c file. That is it. No 'configure'. No makefile. No external libraries except what is guaranteed to be available. No other dependencies, except for any working C compiler. > Google a bit - though I recommend looking for a "dvi" viewer rather than > a "div" viewer. Isn't 'dvi' video? It is not unlikely that you'll have to install at least > some bits of a TeX package to get it working (and be prepared for this > to mean /lots/ of files - a full TeXlive installation is /very/ big). > Try xdvi if you can't get evince to work. It's OK, it's not /that/ unreadable. I don't want want to be side-tracked into yet ANOTHER configure/makefile imbroglio which will have its own problems. Just to remind ourselves of the task, it is to compile a few dozen .c and .h files into an application. Not to recreate the entire Linux OS under Windows. > Given your abilities with installing tools on Windows, I assume you have > got some weird version of make on your path. Are makefiles not portable across compilers then? >> "compile .c modules A, B and C >> then link them" > > That's fine for toy programs. Complicated programs need more than that. > The build process for gcc includes generating some of the C files using > bison (a version of yacc). Cannot the logic of a makefile be expressed in English? We're talking about compiling everything from scratch for a new distribution. Some of it already uses English (the .texinfo file, even if it's a bit garbled. Mercifully there was no configure script). >> Building GMP required a configure script of either 20,000 or 30,000 >> lines; I forget which. A 'little inefficient' is putting it mildly. But >> it is completely over the top. > > I thought you said that didn't matter for a build that you don't often do? I just refuse to pander to such scripts. Either I can do it simply, or I don't bother. It's like buying a new appliance and finding that instructions for opening the box are a 2"-thick manual that is 100 times bigger than those for the appliance itself. It seems only I can see that there is something wrong with that. > Supporting two targets is a huge step up from supporting one target. I supported ~2.8 targets, x64, C and x86. The latter didn't have full FP support, so I dropped it reckoning I could use the more portable C target in its place. But it's still more than one. > No sane person would use the initial beta release of gcc for that > purpose. I posted the link as the earliest publicly available archive > of gcc - not as a tool anyone would want to use. I didn't want to use it, just compile it. >> Neatly? Whatever the project happens to be, configure scripts all seem >> to have tens of thousands of lines! All full of complete and utter crap >> (if you don't believe me, take a look). If a script fails at line 17931 >> out of 31625, how the hell is anyone supposed to figure out how to fix it? > > No one /cares/ how big a configure script is! No one cares what is in > it. Exactly. That's why we end up with bloated and lumbering bits of software. But you really don't care if a task that could be done in 100 lines takes 10000? There doesn't seem much point in always striving to get a compiler a little bit faster than before, when the resulting program will run on the same machine struggling with dozens of mega-sized scripts. > It is very rare that configure scripts fail, except in /your/ hands > - and usually a quick google will find the answer. Just pretend that > the configure script is a sort of executable file, not meant to be read > any more than an .exe file is meant to be read. Sure. Like the 50MB executable of the clang compile which, for all that, doesn't contain any standard headers (as I actually thought for a year or two, not realising it was using gcc's), and doesn't contain a linker. WTF /is/ inside it then?! (My own compiler will probably be 0.3MB and /will/ contain those components.) But it apparently doesn't matter: 50MB, 5GB, who cares? > It is mostly generated automatically - it is not made to be read by people. I generate code, and still have enough pride in its appearance to take extra trouble to keep it readable as much as possible. > Windows is a PITA for development and compilation. It is certainly a PITA if your tools are designed to work with Linux. But it is that dependency that makes it so. That's why my apps only have a dependency on a C compiler and linker. > When I have to use > it, I prefer to stick to ready-built packages and let other people find > the right tools. But I've built cross-gcc for embedded targets on > Windows - I don't have anything like the kind of trouble you seem to > get. I believe you have a unique talent for it - you are so convinced > that it is hard that you give yourself extra problems. I suppose it couldn't be that the problems lie elsewhere or that the people creating these distributions care little about verifying their use on anything other than Linux? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-22 09:22 -0800 |
| Message-ID | <7b1cf0f5-8286-43ef-b686-f6207a8fc271@googlegroups.com> |
| In reply to | #104384 |
On Wednesday, February 22, 2017 at 5:18:25 PM UTC, Bart wrote: > > > Windows is a PITA for development and compilation. > > It is certainly a PITA if your tools are designed to work with Linux. > > But it is that dependency that makes it so. That's why my apps only have > a dependency on a C compiler and linker. > Take a look at Baby X. It is designed to run with minimal configuration. My initial hope of compiling with a simple gcc *.c proved to be unrealistic. Since it's a windowing system of course it has dependencies on Windows and Linux, depending on which version you choose, but your GUI code depends only on Baby X.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-22 19:20 +0000 |
| Message-ID | <o8ko74$tue$1@dont-email.me> |
| In reply to | #104385 |
On 22/02/2017 17:22, Malcolm McLean wrote: > On Wednesday, February 22, 2017 at 5:18:25 PM UTC, Bart wrote: >> >>> Windows is a PITA for development and compilation. >> >> It is certainly a PITA if your tools are designed to work with Linux. >> >> But it is that dependency that makes it so. That's why my apps only have >> a dependency on a C compiler and linker. >> > Take a look at Baby X. > > It is designed to run with minimal configuration. My initial hope of compiling with > a simple gcc *.c proved to be unrealistic. Since it's a windowing system of course > it has dependencies on Windows and Linux, depending on which version you > choose, but your GUI code depends only on Baby X. I just tried it (a version from Sep 2014), and it compiles, links and runs fine with lccwin 32-bits. (Using the 'testbed' demo.) And eventually it worked with gcc -m32, after I'd figured out how to link to Windows dlls (usually it does it automatically, this time it needed -lgdi32). But any other compiler and/or using 64 bits causes assorted problems. I'll have to look at it some more to see how why it works on some compilers and not on others. For example, 'windowsx.h' is used, but Tiny C doesn't have that header (maybe it doesn't need it). Then there are linking problems. Or GWL_USERDATA is undefined in 64-bit mode. (I tried 5 different compilers, and limited tests with MSVC as that's not linked to my IDE) But these are the typical sorts of problems you expect. The actual build instructions are straightforward: compile these 29 or so files then link them together. Does it really need to be more complicated than that? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-22 11:34 -0800 |
| Message-ID | <14043da3-bb9f-4a56-a45b-a21115587a1e@googlegroups.com> |
| In reply to | #104395 |
On Wednesday, February 22, 2017 at 7:21:08 PM UTC, Bart wrote: > On 22/02/2017 17:22, Malcolm McLean wrote: > > I just tried it (a version from Sep 2014), and it compiles, links and > runs fine with lccwin 32-bits. (Using the 'testbed' demo.) > > And eventually it worked with gcc -m32, after I'd figured out how to > link to Windows dlls (usually it does it automatically, this time it > needed -lgdi32). > > But any other compiler and/or using 64 bits causes assorted problems. > I'll have to look at it some more to see how why it works on some > compilers and not on others. For example, 'windowsx.h' is used, but Tiny > C doesn't have that header (maybe it doesn't need it). Then there are > linking problems. Or GWL_USERDATA is undefined in 64-bit mode. > > (I tried 5 different compilers, and limited tests with MSVC as that's > not linked to my IDE) > > But these are the typical sorts of problems you expect. The actual build > instructions are straightforward: compile these 29 or so files then link > them together. Does it really need to be more complicated than that? > Thanks for giving it a try. You have to hang a pointer onto a window through some mechanism or other. That's all GWL_USERDATA is doing. But if it has been broken in a subsequent version of Windows, that is a big deal. Breaking the compile makes Baby X substantially less valuable. This of course is why I want to move the community to B64.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-22 11:49 -0800 |
| Message-ID | <e32a83ec-24ef-4d11-beb4-7071a1ec951f@googlegroups.com> |
| In reply to | #104395 |
On Wednesday, February 22, 2017 at 1:21:08 PM UTC-6, Bart wrote: > But any other compiler and/or using 64 bits causes assorted problems. The first gcc was written at a time before there were any "fixed-size" integer types, but also when there was no reason to expect that an implementation for an octet-based computer would ever need to use "short" for anything other than 16 bits, or "long" for anything other than 32 bits. Since code which needs a 64-bit type could use some other new type (e.g. "long long") invented for that purpose, the only reason an octet-based machine would ever need to use the name "long" for anything bigger than 32 bits would be if a platform were unable to process 32-bit values as efficiently as 64-bit ones, making a 32-bit "int" impractical [since that *still* hasn't happened, I see no reason why the concept of "short==16 bits, long==32 bits, and int==16 or 32 bits at the compiler's leisure" should not have remained the normal paradigm for microcomputers. I think gcc uses its own defines for 16-bit and 32-bit types instead of "short" and "long", but it naturally has no provision to automatically adjust the size of such types for machines where "long" isn't 32 bits.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-22 20:11 +0000 |
| Message-ID | <87mvde6l5s.fsf@bsb.me.uk> |
| In reply to | #104384 |
BartC <bc@freeuk.com> writes: <snip> > I'll have another go. However, if the process depends on 'Make sure > the Bison parser generator is installed', then I'm screwed > anyway. (I've no idea how to do that, and I expect it I will have its > own configure and makefile issues.) sudo apt-get install bison? > THIS is why I'm keen to show how this stuff can be done: One .c > file. That is it. A single-file C compiler is certainly possible. I don't think you have to show it *can* be done. The more interesting question is whether it *should* be done and what, if any, are the costs and limits that that style imposes. You appear to have a particular set of circumstances that make this solution desirable but I'm not sure what they are but I don't seem to share them. <snip> > Just to remind ourselves of the task, it is to compile a few dozen .c > and .h files into an application. Not to recreate the entire Linux OS > under Windows. It's to try to get a highly idiosyncratic bit of old (pre-standard) C compiled. I'm not sure why you are doing this (it certainly won't ever work on my system), but don't pretend you are trying to compile, say, wc. <snip> >> When I have to use >> it, I prefer to stick to ready-built packages and let other people find >> the right tools. But I've built cross-gcc for embedded targets on >> Windows - I don't have anything like the kind of trouble you seem to >> get. I believe you have a unique talent for it - you are so convinced >> that it is hard that you give yourself extra problems. > > I suppose it couldn't be that the problems lie elsewhere or that the > people creating these distributions care little about verifying their > use on anything other than Linux? Why do you think they should? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-22 21:45 +0000 |
| Message-ID | <o8l0n2$tk9$1@dont-email.me> |
| In reply to | #104398 |
On 22/02/2017 20:11, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> I'll have another go. However, if the process depends on 'Make sure >> the Bison parser generator is installed', then I'm screwed >> anyway. (I've no idea how to do that, and I expect it I will have its >> own configure and makefile issues.) > > sudo apt-get install bison? > >> THIS is why I'm keen to show how this stuff can be done: One .c >> file. That is it. > > A single-file C compiler is certainly possible. I don't think you have > to show it *can* be done. The more interesting question is whether it > *should* be done and what, if any, are the costs and limits that that > style imposes. > You appear to have a particular set of circumstances that make this > solution desirable but I'm not sure what they are but I don't seem to > share them. Yes, the set of circumstances is not working on Linux or Unix where you get your hand held: everything is provided, all the dependencies are present, all the scripts work, everything is just right. And if something is missing, then the hard work has already been done as you just have to do 'apt-get'. I don't have all that as I work on Windows, and I don't want it nor believe things needs to be done that way. On Linux all these tools (I believe 'configure' files are generated by a tool, and apparently it is completely unrestrained in what junk it can create) are there so people use them even when unnecessary. Then insist anyone building even the simplest project anywhere else has to source the same set of tools and dependencies, which may or may not work. If an open source project is advertised as 'C source' then building should need nothing more than a C compiler and a linker. But apparently even that can't be kept simple: my gcc is 750MB; when I downloaded GHC Haskell, it came with a bundled C compiler, and wouldn't you know it had to be gcc! 300MB of it (although lost in the 2GB GHC). I strongly think that things can be much smaller and simpler (and yes I know much of that gcc are bundled libraries and stuff, but I wouldn't know how much of it constitutes a basic C system). My projects are /distributed/ as single file C sources, but that is for convenience and minimal hassle. The actual sources might be a couple of dozen modules, and are not even in C. I expend some effort to make building a project for distribution much simpler than it is for development; no else seems that bothered > <snip> >> Just to remind ourselves of the task, it is to compile a few dozen .c >> and .h files into an application. Not to recreate the entire Linux OS >> under Windows. > > It's to try to get a highly idiosyncratic bit of old (pre-standard) C > compiled. I didn't know what is was like. A C compiler reads one text file and outputs another, or perhaps a binary file. It's the perfect example of a portable application that needs only a file API and little else. If should not care what system it runs under. I'm not sure why you are doing this (it certainly won't ever > work on my system), but don't pretend you are trying to compile, say, > wc. And wc is another, if you mean the word-count utility. (But I'm not sure what your point is here.) The first version I bring up, however, requires fcntl.h, shlib.h and unistd.h. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-22 23:13 +0100 |
| Message-ID | <o8l29v$3k7$1@dont-email.me> |
| In reply to | #104403 |
On 22/02/17 22:45, BartC wrote: > If an open source project is advertised as 'C source' then building > should need nothing more than a C compiler and a linker. Please provide a reference for where gcc is advertised as "C source". > > My projects are /distributed/ as single file C sources, but that is for > convenience and minimal hassle. The actual sources might be a couple of > dozen modules, and are not even in C. I expend some effort to make > building a project for distribution much simpler than it is for > development; no else seems that bothered You do realise that a key aspect of free and open source software is that they are provided as /source/ ? The choice of formats for distribution of programs such as gcc is to give the user maximum ability to modify the source - /not/ to give them minimum installation effort. Most people get their minimum installation effort using "apt-get install" or similar tools for their system. (And yes, it is totally true that a great many people involved in such software spend very little time or effort trying to make life easier for users of closed-source proprietary operating systems.)
[toc] | [prev] | [next] | [standalone]
Page 4 of 27 — ← Prev page 1 2 3 [4] 5 6 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web