Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #88990 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2016-06-13 01:15 +0200 |
| Last post | 2016-06-18 08:39 -0700 |
| Articles | 20 on this page of 364 — 23 participants |
Back to article view | Back to comp.lang.c
Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 01:15 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 08:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 02:07 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:48 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 10:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 13:54 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 13:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-13 15:26 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 17:48 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 10:05 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:03 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 14:06 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 22:21 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:59 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 11:19 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:32 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 19:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 20:28 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 12:45 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:29 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 15:03 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:11 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-15 16:14 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:04 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:47 -0500
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-23 20:26 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 21:30 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:33 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 18:51 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-13 16:35 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-14 08:38 +0000
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 16:42 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 17:05 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:31 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 11:20 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 13:38 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 15:21 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 15:44 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 16:15 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 16:32 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 22:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 14:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 23:05 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-14 15:12 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 23:16 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 07:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 11:39 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:04 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 09:33 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 21:27 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 13:41 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 00:48 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:24 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 08:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 09:06 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:12 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:31 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:03 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 08:42 -0700
Kiki's killfile (Was: Small Device C Compiler 3.6.0 released) gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-16 17:03 +0000
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:16 +0000
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-18 16:49 -0500
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 23:42 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 17:35 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 01:19 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 08:21 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 23:10 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:54 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 01:09 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 07:13 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 05:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 08:12 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:18 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-17 21:57 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 20:54 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-17 23:21 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 05:18 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:19 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:40 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:37 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 22:08 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:02 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 00:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 22:33 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-19 12:07 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 10:38 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 21:07 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-19 13:36 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 13:50 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 22:42 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 23:16 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 00:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:33 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 08:09 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 16:57 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-20 14:23 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 15:56 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 01:24 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-19 17:51 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 02:33 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 01:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:10 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 02:22 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 10:51 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:12 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-20 11:32 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 03:59 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 12:19 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 04:40 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 13:05 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 05:32 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 16:22 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 17:13 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 10:11 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 21:39 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:10 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:14 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 17:27 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-22 08:24 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 20:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-22 23:23 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-23 08:15 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-23 20:48 +0100
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-20 23:48 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:02 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-21 03:45 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 20:27 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 10:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-21 02:44 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 12:51 +0200
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-21 10:14 -0500
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:44 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-21 19:50 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 16:33 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 10:54 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-21 20:02 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-21 21:13 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-21 13:45 -0700
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-20 10:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 22:07 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 19:08 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-22 01:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-20 12:38 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-20 15:48 +0100
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-20 23:17 -0500
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-20 21:43 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-21 06:36 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-06-18 12:48 -0500
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-18 23:11 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 21:06 -0700
Re: Small Device C Compiler 3.6.0 released Richard Damon <Richard@Damon-Family.org> - 2016-06-19 08:23 -0400
Re: Small Device C Compiler 3.6.0 released Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:30 -0500
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 09:43 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:55 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 16:29 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:42 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:23 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 10:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 15:53 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:40 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 09:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 17:41 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 08:11 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 11:59 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 09:52 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 18:24 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 14:33 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 12:57 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:12 -0400
Re: Small Device C Compiler 3.6.0 released Ian Collins <ian-news@hotmail.com> - 2016-06-18 09:16 +1200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:16 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:32 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 15:02 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:45 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 18:34 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 18:06 +0100
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:06 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-17 21:49 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 02:18 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 19:00 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 22:36 -0400
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:28 +0000
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:00 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 03:31 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 20:00 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 15:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:20 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 02:13 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 11:44 +0200
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 10:47 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 03:41 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 11:49 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 10:52 +0000
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:18 +0200
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 23:59 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 10:20 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 10:30 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 12:55 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 12:39 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:11 +0200
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:44 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:38 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:07 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:23 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 13:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 21:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 14:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 23:28 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 15:35 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 01:11 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 18:01 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 18:44 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 19:42 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 13:06 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:06 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:40 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:09 -0700
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:51 +0800
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 10:32 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 11:00 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 12:59 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 12:34 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 13:56 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 13:15 +0100
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 14:33 +0200
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 08:47 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:51 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:39 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:36 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 21:54 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 17:05 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:05 -0700
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:34 +0000
Re: Small Device C Compiler 3.6.0 released Reinhardt Behm <rbehm@hushmail.com> - 2016-06-17 20:43 +0800
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 06:15 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-17 15:47 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 07:51 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 11:52 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-17 14:57 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:37 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 16:48 -0700
Re: Small Device C Compiler 3.6.0 released Richard Heathfield <rjh@cpax.org.uk> - 2016-06-19 00:50 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:30 -0700
Re: Small Device C Compiler 3.6.0 released Les Cargill <lcargill99@comcast.com> - 2016-06-19 06:35 -0500
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 01:29 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 17:43 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-19 02:00 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-18 18:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 17:14 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-19 15:17 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 14:52 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 12:32 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 20:55 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:09 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 16:19 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 16:48 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:01 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 17:38 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 21:55 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:56 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 06:36 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 16:43 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 09:13 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 18:49 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 11:46 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 21:03 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 13:30 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 11:17 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 01:18 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 17:53 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-17 18:20 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:37 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 10:30 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 07:52 -0400
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:59 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-17 22:01 -0700
Re: Small Device C Compiler 3.6.0 released gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-18 10:02 +0000
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 21:10 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 06:45 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:00 +0100
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 10:35 -0400
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 09:07 -0700
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 15:32 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 17:03 +0100
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-06-16 22:26 +0000
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 23:44 +0100
Re: Small Device C Compiler 3.6.0 released luser droog <luser.droog@gmail.com> - 2016-06-16 16:56 -0700
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:03 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-18 13:43 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-16 16:35 -0700
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 20:57 -0400
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-16 21:12 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:31 -0400
Re: Small Device C Compiler 3.6.0 released Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 22:32 -0400
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 19:59 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-17 03:11 -0700
Re: Small Device C Compiler 3.6.0 released James Kuyper <jameskuyper@verizon.net> - 2016-06-17 09:11 -0400
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:20 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:24 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 18:16 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 11:15 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:09 +0100
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 11:32 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-15 12:01 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-15 20:15 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:15 +0000
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:12 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 13:03 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 04:22 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-15 14:20 +0200
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:33 +0000
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-06-18 12:00 +0100
Re: Small Device C Compiler 3.6.0 released raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:39 +0000
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-15 09:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 14:38 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-13 15:09 -0700
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-14 09:51 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-13 23:19 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 23:46 +0100
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 19:04 -0400
Re: Small Device C Compiler 3.6.0 released "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-13 20:04 -0400
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 00:23 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 11:17 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 02:08 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 08:37 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 08:56 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-14 09:14 -0700
Re: Small Device C Compiler 3.6.0 released Keith Thompson <kst-u@mib.org> - 2016-06-18 11:47 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-14 10:59 +0100
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-14 12:54 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 05:38 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-13 22:56 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-15 10:09 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 15:09 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 14:39 +0200
Re: Small Device C Compiler 3.6.0 released David Brown <david.brown@hesbynett.no> - 2016-06-16 15:11 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 14:28 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 21:25 +0200
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 12:40 -0700
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-16 22:00 +0200
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 21:14 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-16 14:08 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-16 22:30 +0100
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:31 +0200
Re: Small Device C Compiler 3.6.0 released Philipp Klaus Krause <pkk@spth.de> - 2016-06-17 13:28 +0200
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:38 -0700
Re: Small Device C Compiler 3.6.0 released BartC <bc@freeuk.com> - 2016-06-17 10:53 +0100
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-06-18 08:39 -0700
Page 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 16:22 +0100 |
| Message-ID | <nk91oa$jt0$1@dont-email.me> |
| In reply to | #89655 |
On 20/06/16 15:53, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 20/06/16 12:40, Malcolm McLean wrote:
>>> On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote:
>>>> On 20/06/16 11:12, Malcolm McLean wrote:
>>>>
>>>>> A recursive function is not just another subroutine call.
>>>>> It has properties which are fundamentally different.
>>>>
>>>> Do please share what these fundamentally different properties are.
>>>>
>>> A tree with a cycle in it has different properties to a tree without. It's
>>> no longer strictly a tree.
>>
>> You lost the tree when you allowed loops.
>
> How can you tell? Do you really think that Malcolm has given the
> construction with enough detail that you can argue about the result? If
> so, please explain the construction to me!
I keep thinking I follow it, and he keeps surprising me, but this is
what I've got in my head thing:
To make the description as clear as possible, I'm going to refer to the
textual layout, assuming perfectly applied Allman style but with
one-space indents, like this:
main()
{
foo();
if(bar)
{
baz();
}
}
where every if() is always followed by braces. This is not an essential
component of the source, but I think it'll make it easier to talk about.
A 'node' is defined to be either a decision point or a function. Any
node can be a parent node. Any node except main can be a child node (so
main is the root node). To construct the tree, then, you start at main.
main's child nodes are at Indent Level 1, main itself being Level 0. In
the above example, main's children are foo() and if(). Add each of
main's child nodes to the tree:
main ---+-----+
| |
foo if
main is now done.
We now look at each identified but unprocessed child node in turn,
considering it in its new role as potential parent. Every time a new
child node is identified, it must be added to the list of identified but
unprocessed child nodes. (This is just a terrible way of saying "keep
building the tree recursively until you run out of program".)
For each node N at Indent Level L:
{
If N is a decision point (if/for/while/switch):
{
In the following block statement, each function
call or decision point at Indent Level L+1 is
considered a child of N. Add the node to N's
list of children, and mark it as unprocessed.
}
else if N is a function call to F():
{
make a note of where you've got to, and recurse
into F(), applying the same rules again. See
below for how to handle any calls to F() within
F().
}
Mark N as processed.
}
Note that, if F() is called many times, it will be processed many times,
as each invocation is considered a separate node.
Recursive F() needs to be handled as a special case because otherwise
our little tree-building parser will disappear up its own exhaust pipe
(we can't expect the tree-builder to establish the state of the base
case). The special-case fix could be as simple as a Boolean flag
(recursive yes/no) in the node's internal data structure, with the flag
printed on the output:
\
\
\
\
+----------------+
| F() |
| recursive? Yes |
+----------------+
I *think* that does it. You can replace my artificial "indent level"
measure with equivalent node-depth logic (to remove reliance on
pretty-printed source), and you can remove my "every control statement
is followed by a block statement" requirement by adding appropriate
processing of a single-statement control body.
Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
at all sure of is what point he sees in insisting that it must be a tree.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 17:13 +0100 |
| Message-ID | <87shw7on3n.fsf@bsb.me.uk> |
| In reply to | #89657 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/06/16 15:53, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 20/06/16 12:40, Malcolm McLean wrote:
>>>> On Monday, June 20, 2016 at 12:19:36 PM UTC+1, Richard Heathfield wrote:
>>>>> On 20/06/16 11:12, Malcolm McLean wrote:
>>>>>
>>>>>> A recursive function is not just another subroutine call.
>>>>>> It has properties which are fundamentally different.
>>>>>
>>>>> Do please share what these fundamentally different properties are.
>>>>>
>>>> A tree with a cycle in it has different properties to a tree without. It's
>>>> no longer strictly a tree.
>>>
>>> You lost the tree when you allowed loops.
>>
>> How can you tell? Do you really think that Malcolm has given the
>> construction with enough detail that you can argue about the result? If
>> so, please explain the construction to me!
>
> I keep thinking I follow it, and he keeps surprising me, but this is
> what I've got in my head thing:
>
> To make the description as clear as possible, I'm going to refer to
> the textual layout, assuming perfectly applied Allman style but with
> one-space indents, like this:
>
> main()
> {
> foo();
> if(bar)
> {
> baz();
> }
> }
>
> where every if() is always followed by braces. This is not an
> essential component of the source, but I think it'll make it easier to
> talk about.
>
> A 'node' is defined to be either a decision point or a function. Any
> node can be a parent node. Any node except main can be a child node
> (so main is the root node). To construct the tree, then, you start at
> main.
>
> main's child nodes are at Indent Level 1, main itself being Level
> 0. In the above example, main's children are foo() and if(). Add each
> of main's child nodes to the tree:
>
> main ---+-----+
> | |
> foo if
>
> main is now done.
>
> We now look at each identified but unprocessed child node in turn,
> considering it in its new role as potential parent. Every time a new
> child node is identified, it must be added to the list of identified
> but unprocessed child nodes. (This is just a terrible way of saying
> "keep building the tree recursively until you run out of program".)
It does not look recursive to me (other than in the trivial sense that
it could be written as a recursive function). If the construction were
depth-first I'd call it recursive but I think you are expanding the tree
breadth first.
> For each node N at Indent Level L:
> {
> If N is a decision point (if/for/while/switch):
> {
> In the following block statement, each function
> call or decision point at Indent Level L+1 is
> considered a child of N. Add the node to N's
> list of children, and mark it as unprocessed.
> }
> else if N is a function call to F():
> {
> make a note of where you've got to, and recurse
> into F(), applying the same rules again. See
> below for how to handle any calls to F() within
> F().
> }
> Mark N as processed.
> }
>
> Note that, if F() is called many times, it will be processed many
> times, as each invocation is considered a separate node.
>
> Recursive F() needs to be handled as a special case because otherwise
> our little tree-building parser will disappear up its own exhaust pipe
> (we can't expect the tree-builder to establish the state of the base
> case). The special-case fix could be as simple as a Boolean flag
> (recursive yes/no) in the node's internal data structure, with the
> flag printed on the output:
>
> \
> \
> \
> \
> +----------------+
> | F() |
> | recursive? Yes |
> +----------------+
>
> I *think* that does it. You can replace my artificial "indent level"
> measure with equivalent node-depth logic (to remove reliance on
> pretty-printed source), and you can remove my "every control statement
> is followed by a block statement" requirement by adding appropriate
> processing of a single-statement control body.
>
> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm
> not at all sure of is what point he sees in insisting that it must be
> a tree.
Considering only the parts that relate to function calls, that's what I
though too, except for the key part about recursive calls. You've had
to guess and I am sure you are wrong in that guess because your rule
does not make a cyclic graph.
My best guess so far is as above except that
(a) the recursive call is spotted and a new node is node generated.
Instead, the tree is made into a loop because he really wants a loop;
(b) calls that don't use the function name are just not handled making
such programs not Malcolm-structured programs.
Both of these are at odds with how the world sees structured
programming.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 10:11 -0700 |
| Message-ID | <29efc4b9-fffc-45de-aec4-ce131c12e9ab@googlegroups.com> |
| In reply to | #89657 |
On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote:
>
> I keep thinking I follow it, and he keeps surprising me, but this is
> what I've got in my head thing:
>
> To make the description as clear as possible, I'm going to refer to the
> textual layout, assuming perfectly applied Allman style but with
> one-space indents, like this:
>
> main()
> {
> foo();
> if(bar)
> {
> baz();
> }
> }
>
> where every if() is always followed by braces. This is not an essential
> component of the source, but I think it'll make it easier to talk about.
>
> A 'node' is defined to be either a decision point or a function. Any
> node can be a parent node. Any node except main can be a child node (so
> main is the root node). To construct the tree, then, you start at main.
>
> main's child nodes are at Indent Level 1, main itself being Level 0. In
> the above example, main's children are foo() and if(). Add each of
> main's child nodes to the tree:
>
> main ---+-----+
> | |
> foo if
>
> main is now done.
>
> We now look at each identified but unprocessed child node in turn,
> considering it in its new role as potential parent. Every time a new
> child node is identified, it must be added to the list of identified but
> unprocessed child nodes. (This is just a terrible way of saying "keep
> building the tree recursively until you run out of program".)
>
> For each node N at Indent Level L:
> {
> If N is a decision point (if/for/while/switch):
> {
> In the following block statement, each function
> call or decision point at Indent Level L+1 is
> considered a child of N. Add the node to N's
> list of children, and mark it as unprocessed.
> }
> else if N is a function call to F():
> {
> make a note of where you've got to, and recurse
> into F(), applying the same rules again. See
> below for how to handle any calls to F() within
> F().
> }
> Mark N as processed.
> }
>
> Note that, if F() is called many times, it will be processed many times,
> as each invocation is considered a separate node.
>
> Recursive F() needs to be handled as a special case because otherwise
> our little tree-building parser will disappear up its own exhaust pipe
> (we can't expect the tree-builder to establish the state of the base
> case). The special-case fix could be as simple as a Boolean flag
> (recursive yes/no) in the node's internal data structure, with the flag
> printed on the output:
>
> \
> \
> \
> \
> +----------------+
> | F() |
> | recursive? Yes |
> +----------------+
>
> I *think* that does it. You can replace my artificial "indent level"
> measure with equivalent node-depth logic (to remove reliance on
> pretty-printed source), and you can remove my "every control statement
> is followed by a block statement" requirement by adding appropriate
> processing of a single-statement control body.
>
> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
> at all sure of is what point he sees in insisting that it must be a tree.
>
You've more or less got it.
If we write a leaf function in the structured programming way, it calls
no subroutines, and is a tree, with the blocks forming children
for lops and ifs. Conventionally we indent the source to make the tree
structure obvious.
If we write a non-leaf function, which calls a leaf subroutine, we
can convert it to a leaf function, by inlining the subroutine.
So we've got a tree of blocks.
If we've got a function that takes a function pointer as an argument,
and calls it, we can still convert the function to leaf by inlining the call,
if we can determine the value of the function pointer at compile time.
We can't do this if the function pointer is dynamically bound.
If we've got a function which calls itself, either directly or indirectly,
we can't convert the function to leaf.
If we can convert the entire program to leaf, we can run it on a system
that doesn't support subroutines.
But if we don't adhere to structure programming rules strictly, we
can still convert the program to leaf, but now it won't be a strict
tree of blocks. it will likely be close, however, with just a few jumps
into and out of what are C "blocks", code within curly braces, but
not structured programming block.
However all the code that we have expanded from the subroutines
must be a "block" in the structured programming sense. We can't have
jumps into the subroutine except from the point of call, we can't have
jumps out of it except to the point of return, which is one step
below the point of call.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 21:39 +0100 |
| Message-ID | <87a8ifoar2.fsf@bsb.me.uk> |
| In reply to | #89664 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: <snip> >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. <snip> > You've more or less got it. Except Richard's constructed trees do not have any cycles -- he leaves that part but vague because you have left it vague. I fear you are determined never to explain the tree construction for fear of being too clear. After all, it's not as if any of this is hard to understand, it's just unspecified. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:10 -0700 |
| Message-ID | <51b70d0a-647d-4ed5-a83c-74707ba91eba@googlegroups.com> |
| In reply to | #89671 |
On Monday, June 20, 2016 at 9:39:53 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Except Richard's constructed trees do not have any cycles -- he leaves > that part but vague because you have left it vague. I fear you are > determined never to explain the tree construction for fear of being too > clear. After all, it's not as if any of this is hard to understand, > it's just unspecified. > Yes, because recursion breaks the tree-like structure. It's no longer a tree. That's the whole point.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 01:14 +0100 |
| Message-ID | <87r3bqkrkv.fsf@bsb.me.uk> |
| In reply to | #89684 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 9:39:53 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Except Richard's constructed trees do not have any cycles -- he leaves >> that part but vague because you have left it vague. I fear you are >> determined never to explain the tree construction for fear of being too >> clear. After all, it's not as if any of this is hard to understand, >> it's just unspecified. >> > Yes, because recursion breaks the tree-like structure. It breaks *a* tree-like structure that you've made up for the purpose. The dynamic call tree in a tree in all cases, and the static call graph has cycles in the case of recursion but that's not always a tree in its absence. (I'm at fault myself for writing the "here" because both of these standard constructs can be defined in slightly different ways.) > It's no longer a tree. > That's the whole point. I think everyone here knows this now. The whole point of your never to be clarified construction is to special-case the features you don't like. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-21 17:27 -0700 |
| Message-ID | <c9945646-d5d1-405a-b9a2-720418083cfb@googlegroups.com> |
| In reply to | #89743 |
On Wednesday, June 22, 2016 at 1:14:33 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's no longer a tree. > > That's the whole point. > > I think everyone here knows this now. The whole point of your never to > be clarified construction is to special-case the features you don't > like. > Trees are where it's at. Trees, trees. Trees are tractable, graphs are not. As a general rule, if you can get your data into a tree structure, you can deal with it. If you can't then there are likely to be all sorts of difficult problems cropping up. That applies to code as much as to data. The reason I dislike certain structures are that they break the tree. I didn't invent "the tree". The person who first represented a program using indents for nested blocks did that. And no, I don't know who it was. But it wasn't me, I can assure you of that. I am genuinely the inventor of bit-based programming. But I've been careful to keep my own ideas out of this discussion.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-22 08:24 -0700 |
| Message-ID | <db4f9ef1-ef77-4bb0-a0d8-fca1f1dc524e@googlegroups.com> |
| In reply to | #89747 |
On Tuesday, June 21, 2016 at 7:27:47 PM UTC-5, Malcolm McLean wrote: > Trees are where it's at. > Trees, trees. > > Trees are tractable, graphs are not. As a general rule, if you can > get your data into a tree structure, you can deal with it. If you can't > then there are likely to be all sorts of difficult problems > cropping up. > That applies to code as much as to data. Are you familiar with the term "DAG"? A DAG is a Directed Acyclic Graph, which has the property that edge is marked with a direction, and there will never be a path from any node to itself. Dags are sometimes harder to represent visually than trees, but can be represented with far less redundancy. I would suggest that dags should really be "where it's at" in many cases. Recursion won't work in a dag any better than it works in a tree, but in many cases where a program uses recursion removing a small number of edges would turn the graph into a DAG; the compiler can't omit the recursive calls, of course, but it can add code to save context before them and restore context afterward. Like trees, DAGs have the useful property that they can be organized into levels two ways: maximum distance from root, or maximum distance to leaf. If you've not looked at DAGs before, I highly recommend it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 20:00 +0100 |
| Message-ID | <87twgljbga.fsf@bsb.me.uk> |
| In reply to | #89747 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 22, 2016 at 1:14:33 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > It's no longer a tree. >> > That's the whole point. >> >> I think everyone here knows this now. The whole point of your never to >> be clarified construction is to special-case the features you don't >> like. >> > Trees are where it's at. Agreed. > Trees, trees. Agreed. Agreed. > Trees are tractable, graphs are not. Which is why I would not invent a rule to turn the simple dynamic call tree into a graph. <snip> > The reason I dislike certain structures are that they break the tree. You've done it again. They break *a* tree. They don't break the dynamic call tree. I have to conclude that you are doing this deliberately -- you can't be so unaware of your use of language. > I didn't invent "the tree". No, you invented "a tree" and, since you can't site any other uses of it in relation to structured programming, I will continue to say you did. And I'd still like to see you actually state the rules for constructing the Malcolm-call-tree, in part so I can see how you ban calling functions through pointer parameters (or, no doubt, other data). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-22 23:23 -0700 |
| Message-ID | <43357a4a-c611-4176-8e7f-296d839b4948@googlegroups.com> |
| In reply to | #89759 |
On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote: > > And I'd still like to see you actually state the rules for constructing > the Malcolm-call-tree, in part so I can see how you ban calling > functions through pointer parameters (or, no doubt, other data). > It's very simple and natural. A function is a node, its subroutines are children, and each child appears as many times as it is called from separate places. It's not too important if you draw the tree as a DAG, because shared subroutines are identical, or if you merge identical children. Unless a child takes a function pointer as a parameter. Then its child becomes the function passed by indirection and its no longer true that identical children have the same children. (You might ask how a node can be "identical" to another node and have different children, the answer is that physically the nodes are the same machine instructions, so "identical" in that sense). However dynamic binding makes it difficult to draw the tree. You could work out all possible values of the pointer and draw separate children, but that gets less and less practical as dynamic binding becomes your structuring method of choice. And recursion either adds cycles to the tree, or in the case of recursion with the number of steps known at compile time adds a known but likely excessive number of identical child/grandchild steps, or in the case of the number of steps not being known at compile time, turns the tree into a dynamic structure that varies on each call. So recursion is not disastrous, especially if used lightly, but it's very much a special case. Trees are more tractable than graphs, even DAGs, that's the first reason for thinking of it as a tree rather than a DAG. The second is to accommodate function pointers. The third is for consistency with the structured programming model for programs without subroutines. The fourth is that we have a unique path from leaf back to parent. The fifth is that each branch becomes independent. The sixth is that subroutines used as structuring elements, and which appear once, are rather different from subroutines used for code reuse, which appear several times and are designed to be exposed in libraries, and the former is the main focus of interest here, mostly you'll just declare your library subroutines like printf to be "leaf". A subroutine in C is virtually constrained to be a block, unless you use special flow control routines like longjmp() or exit(), or unless it never returns. A block has a single point of entry and a single point of exit. However subroutines are not constrained to be written in the structured programming way, and quite often aren't, with the most common violation being multiple returns. Structured programming is robust. If a block is not internally structured, that doesn't render the blocks it contains non- structured, and it doesn't prevent it from being a component of a structured programming block. So a tree of subroutines rather than a tree of blocks makes sense. However if you inline all subroutines you are not really changing the structure of the program, in fact the tree becomes more obvious because its given by indentation (though you've got to have if nodes and loop nodes, which the subroutine tree ignores). In practical terms, people think in subroutines. A programmer can usually tell you which subroutines he wrote today and what they do, he's much less likely to be able to tell you which if blocks he wrote and what they do.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-23 08:15 -0700 |
| Message-ID | <lnwplgos1r.fsf@kst-u.example.com> |
| In reply to | #89760 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote:
>> And I'd still like to see you actually state the rules for constructing
>> the Malcolm-call-tree, in part so I can see how you ban calling
>> functions through pointer parameters (or, no doubt, other data).
>>
> It's very simple and natural.
> A function is a node, its subroutines are children, and each child
> appears as many times as it is called from separate places.
Are you using the word "function" in the same way the C standard does?
Is "subroutine" synonymous with "function"? If so, why use two
different words? (If "subroutine" means something different than
"function", I have no further questions, because I'd have no further
interest in dragging out your definitions of standard terms.)
By "its subroutines", do you mean functions that are called from
original function?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-23 20:48 +0100 |
| Message-ID | <87por7it4u.fsf@bsb.me.uk> |
| In reply to | #89760 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 22, 2016 at 8:00:30 PM UTC+1, Ben Bacarisse wrote: >> >> And I'd still like to see you actually state the rules for constructing >> the Malcolm-call-tree, in part so I can see how you ban calling >> functions through pointer parameters (or, no doubt, other data). >> > It's very simple and natural. > A function is a node, its subroutines are children, and each child > appears as many times as it is called from separate places. > It's not too important if you draw the tree as a DAG, because > shared subroutines are identical, or if you merge identical children. Blimey! That's the call graph you rejected as not being the Malcolm-call-tree. You also insisted that nodes were function activations and not functions themselves. That was why why nodes representing the same function could *not* be merged. And this could be either a static or a dynamic construction -- I don't think you've made that clear (the old one was static being based on textual substitution). I don't think there is enough firm ground for meaningful discussion here. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-20 23:48 +0100 |
| Message-ID | <nk9rs9$pef$1@dont-email.me> |
| In reply to | #89664 |
On 20/06/16 18:11, Malcolm McLean wrote: > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: >> <snip> >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not >> at all sure of is what point he sees in insisting that it must be a tree. >> > You've more or less got it. Great! I'm delighted to hear it. In which case, my reaction is that it's completely pointless. If I want to look at what functions a function calls, I can just look at the function. If I want to look at what functions are called inside a loop or an if, I can just look at the loop or the if. No, what I really, /really/ want from such a diagram is "from which places is this function called?", and that's just what your tree doesn't give me. Also, it doesn't handle recursion elegantly. I don't think it handles mutual recursion *at all*, and it would need to be modified to allow this. But, whatever its uses and practicalities (or otherwise), what I really don't see is why you think of this tree as being definitively 'structured'. Neither do I see why you need it to be a tree. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:02 -0700 |
| Message-ID | <b810c036-f755-436b-a63d-647233d556a7@googlegroups.com> |
| In reply to | #89676 |
On Monday, June 20, 2016 at 11:48:49 PM UTC+1, Richard Heathfield wrote: > On 20/06/16 18:11, Malcolm McLean wrote: > > On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote: > >> > <snip> > > >> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not > >> at all sure of is what point he sees in insisting that it must be a tree. > >> > > You've more or less got it. > > Great! I'm delighted to hear it. In which case, my reaction is that it's > completely pointless. If I want to look at what functions a function > calls, I can just look at the function. If I want to look at what > functions are called inside a loop or an if, I can just look at the loop > or the if. No, what I really, /really/ want from such a diagram is "from > which places is this function called?", and that's just what your tree > doesn't give me. > What's the point in structured programming? The so-called Malcolm call-tree is the structure of a structured program. A tree, with cycles for recursion. The entire paradigm is designed to force the program into this pattern. > > Also, it doesn't handle recursion elegantly. I don't think it handles > mutual recursion *at all*, and it would need to be modified to allow this. > > But, whatever its uses and practicalities (or otherwise), what I really > don't see is why you think of this tree as being definitively > 'structured'. Neither do I see why you need it to be a tree. > If we consider just a structured leaf subroutine, there are three main forms of notation for it. The first is using C-style curly brackets with nesting. The second is using strict indentation. The third is using a flow chart. The first two are also common notation for trees. The third isn't obviously tree-like, but is the same structure underneath. Why preserve the property that we can convert subroutines from leaf to non-leaf, whilst preserving the structure of the program? That's a rule. Non-recursive subroutine calls are just blocks, they're not considered special controls in their own right.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-21 03:45 +0100 |
| Message-ID | <nka9ns$rpm$1@dont-email.me> |
| In reply to | #89682 |
On 21/06/16 03:02, Malcolm McLean wrote:
> On Monday, June 20, 2016 at 11:48:49 PM UTC+1, Richard Heathfield wrote:
>> On 20/06/16 18:11, Malcolm McLean wrote:
>>> On Monday, June 20, 2016 at 4:23:02 PM UTC+1, Richard Heathfield wrote:
>>>>
>> <snip>
>>
>>>> Like I said, I'm /fairly/ sure that's how Malcolm sees it. What I'm not
>>>> at all sure of is what point he sees in insisting that it must be a tree.
>>>>
>>> You've more or less got it.
>>
>> Great! I'm delighted to hear it. In which case, my reaction is that it's
>> completely pointless. If I want to look at what functions a function
>> calls, I can just look at the function. If I want to look at what
>> functions are called inside a loop or an if, I can just look at the loop
>> or the if. No, what I really, /really/ want from such a diagram is "from
>> which places is this function called?", and that's just what your tree
>> doesn't give me.
>>
> What's the point in structured programming?
Simplifying the control flow.
> The so-called Malcolm call-tree is the structure of a structured
> program. A tree, with cycles for recursion.
If it has cycles, it's not a tree. If it's not a tree /anyway/, you
might as well leave functions where they are instead of duplicating them
all over the place:
A
|\
B C
|/
D
instead of
A
|\
B C
| \
D D
> The entire paradigm is designed to force the program into this
> pattern.
That's the "MSP" paradigm, not the paradigm that everybody else thinks
of as structured programming.
Believe it or not, I more or less agree with more or less everything
you've said (except, of course, for the bits I don't agree with).
I generally prefer for functions to have one entry point and one exit
point. I prefer for control structures to have one entry point and one
exit point, too. Branches are fine:
|
IF cond
/ \
Y N
\ /
\/
common
and multi-way branches are fine:
|
SWITCH(value)
| | | | | | |
a b c d e f *
\ /
common
and these all sit very well with the idea of a directed acyclic graph,
but they don't work well as trees. Trees don't grow that way.
In 1997 I had the chance to play with the (extraordinarily expensive)
McCabe code complexity analysis toolkit, which could turn C code into
diagrams at the statement level. When I fed this toolkit some C sources
from my client du jour, they looked a bit of a mess but normally not too
bad.
When I fed my own programs to the same analyser, I was delighted to see
that almost without exception they /looked/ beautiful. The structure was
self-evident, and indeed almost crystalline. These were /structured/
programs.
But they were graphs, not trees.
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 20:27 -0700 |
| Message-ID | <699201cb-f47b-42cc-bdd4-7b2048689a8e@googlegroups.com> |
| In reply to | #89685 |
On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote: > On 21/06/16 03:02, Malcolm McLean wrote: > > > The so-called Malcolm call-tree is the structure of a structured > > program. A tree, with cycles for recursion. > > If it has cycles, it's not a tree. If it's not a tree /anyway/, you > might as well leave functions where they are instead of duplicating them > all over the place: > > A > |\ > B C > |/ > D > > instead of > > A > |\ > B C > | \ > D D > Yes, it's not a huge point. Sometimes the former graph makes more sense. Not if D takes a function pointer, however. If D takes a function pointer which is E in B a F in C, the second graph looks like A | \ B C | \ D D | \ E F and we know that F is only called once, and always from C. > > and these all sit very well with the idea of a directed acyclic graph, > but they don't work well as trees. Trees don't grow that way. > The tree is the tree of nested blocks. Blocks nest, that's the crucial point of structured programming. You can certainly see an if node as a flow graph if you want, a flowchart is one common representation. Or you can see it as the node of tree with two children, and the rule that on each visit you traverse one child, but never both. Loops ultimately introduce a cycle. Structured programming cannot solve the halting problem, it just keeps it under control. Most structured programs will terminate and we can easily show that all the loops must terminate. Others will never terminate and we can just as easily show that we have a while(true). Just a few have complex loops where it's hard to show if they terminate or not without dry-running the program. We can't ban both loops and recursion, unfortunately. We have to accept the problem somewhere. > > In 1997 I had the chance to play with the (extraordinarily expensive) > McCabe code complexity analysis toolkit, which could turn C code into > diagrams at the statement level. When I fed this toolkit some C sources > from my client du jour, they looked a bit of a mess but normally not too > bad. > > When I fed my own programs to the same analyser, I was delighted to see > that almost without exception they /looked/ beautiful. The structure was > self-evident, and indeed almost crystalline. These were /structured/ > programs. > > But they were graphs, not trees. > Trees, Richard trees. The world needs more trees. Graphs are ugly. Trees are nice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 10:03 +0200 |
| Message-ID | <nkasda$a12$1@dont-email.me> |
| In reply to | #89686 |
On 21/06/16 05:27, Malcolm McLean wrote: > On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote: >> On 21/06/16 03:02, Malcolm McLean wrote: >> >>> The so-called Malcolm call-tree is the structure of a structured >>> program. A tree, with cycles for recursion. >> >> If it has cycles, it's not a tree. If it's not a tree /anyway/, you >> might as well leave functions where they are instead of duplicating them >> all over the place: >> >> A >> |\ >> B C >> |/ >> D >> >> instead of >> >> A >> |\ >> B C >> | \ >> D D >> > Yes, it's not a huge point. It is /exactly/ the point. The former is a graph (a directed graph), the later is a tree made by replicating nodes on the graph. The graph is a better model for all but the simplest of programs, precisely because it avoids duplication, and because it is a more general structure. In particular, it also supports conditionals in a practical way (as Richard showed), as well as loops /and/ recursion. Recursion leads to cycles in the directed graph, which spoils some analytical properties - but it allows other sorts of analysis (such as proof by induction). The tree only really makes sense if, in the words of the great Jerry Stuckle, the biggest program you write is "Hello, world". > Sometimes the former graph makes more sense. The former graph almost always makes more sense. > > Not if D takes a function pointer, however. If D takes > a function pointer which is E in B a F in C, the second graph > looks like > > A > | \ > B C > | \ > D D > | \ > E F > > and we know that F is only called once, and always from C. Function pointers /always/ make it harder to follow the call structure of a program. It makes sense to avoid them, or at least limit them or constrain them in some way (such as C++ virtual functions) if you want to generate call graphs or do other analysis on your code. And yes, sometimes it would make sense to duplicate the node D in a case like this (the alternative is both E and F coming out of D): A |\ B C |/ D |\ E F But such situations are the exception, not the common case. > > We can't ban both loops and recursion, unfortunately. We have > to accept the problem somewhere. Loops and recursions are not "problems" - if they don't fit well with your particular ideas of program structure or models, then it is your ideas and models that are the problem. Without loops and recursion (or some equivalent constructs), you can't do anything worthwhile in your programming. Your insistence that everything should look like a tree without cycles (and all fitting on one page, according to your earlier posts) is an artificial and unrealistic constraint. Yes, it is easier to analyse a nice clean tree - but it does not match reality. It's like the physicist who wants to make milk production more efficient, and starts off with "consider a spherical cow...". >> >> In 1997 I had the chance to play with the (extraordinarily expensive) >> McCabe code complexity analysis toolkit, which could turn C code into >> diagrams at the statement level. When I fed this toolkit some C sources >> from my client du jour, they looked a bit of a mess but normally not too >> bad. >> >> When I fed my own programs to the same analyser, I was delighted to see >> that almost without exception they /looked/ beautiful. The structure was >> self-evident, and indeed almost crystalline. These were /structured/ >> programs. >> >> But they were graphs, not trees. >> > Trees, Richard trees. > > The world needs more trees. Graphs are ugly. Trees are nice. > Trees are great for climbing - but useless as models of call behaviour and structure in programs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-21 02:44 -0700 |
| Message-ID | <0ba761a3-29f4-4060-9048-c132226a5853@googlegroups.com> |
| In reply to | #89694 |
On Tuesday, June 21, 2016 at 9:04:03 AM UTC+1, David Brown wrote:
> On 21/06/16 05:27, Malcolm McLean wrote:
> > On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote:
> >> On 21/06/16 03:02, Malcolm McLean wrote:
> >>
> >>> The so-called Malcolm call-tree is the structure of a structured
> >>> program. A tree, with cycles for recursion.
> >>
> >> If it has cycles, it's not a tree. If it's not a tree /anyway/, you
> >> might as well leave functions where they are instead of duplicating them
> >> all over the place:
> >>
> >> A
> >> |\
> >> B C
> >> |/
> >> D
> >>
> >> instead of
> >>
> >> A
> >> |\
> >> B C
> >> | \
> >> D D
> >>
> > Yes, it's not a huge point.
>
> It is /exactly/ the point. The former is a graph (a directed graph),
> the later is a tree made by replicating nodes on the graph. The graph
> is a better model for all but the simplest of programs, precisely
> because it avoids duplication, and because it is a more general
> structure. In particular, it also supports conditionals in a practical
> way (as Richard showed), as well as loops /and/ recursion. Recursion
> leads to cycles in the directed graph, which spoils some analytical
> properties - but it allows other sorts of analysis (such as proof by
> induction).
>
> The tree only really makes sense if, in the words of the great Jerry
> Stuckle, the biggest program you write is "Hello, world".
>
> > Sometimes the former graph makes more sense.
>
> The former graph almost always makes more sense.
>
> >
> > Not if D takes a function pointer, however. If D takes
> > a function pointer which is E in B a F in C, the second graph
> > looks like
> >
> > A
> > | \
> > B C
> > | \
> > D D
> > | \
> > E F
> >
> > and we know that F is only called once, and always from C.
>
> Function pointers /always/ make it harder to follow the call structure
> of a program. It makes sense to avoid them, or at least limit them or
> constrain them in some way (such as C++ virtual functions) if you want
> to generate call graphs or do other analysis on your code.
>
The property that all D nodes are the same breaks if D takes and calls
a function pointer. So yes, they complicate things. The tree makes
that obvious.
>
> And yes, sometimes it would make sense to duplicate the node D in a case
> like this (the alternative is both E and F coming out of D):
>
> A
> |\
> B C
> |/
> D
> |\
> E F
>
> But such situations are the exception, not the common case.
>
With that graph, E is reachable from C.
It's not "wrong", it's showing a structure which exists, but it's not
keeping all properties we might desire.
>
> >
> > We can't ban both loops and recursion, unfortunately. We have
> > to accept the problem somewhere.
>
> Loops and recursions are not "problems" - if they don't fit well with
> your particular ideas of program structure or models, then it is your
> ideas and models that are the problem. Without loops and recursion (or
> some equivalent constructs), you can't do anything worthwhile in your
> programming. Your insistence that everything should look like a tree
> without cycles (and all fitting on one page, according to your earlier
> posts) is an artificial and unrealistic constraint. Yes, it is easier
> to analyse a nice clean tree - but it does not match reality. It's like
> the physicist who wants to make milk production more efficient, and
> starts off with "consider a spherical cow...".
>
No, you can't abolish the halting problem simply by structuring your
program.
But we can show that a structured program must return if it has no
loops or recursive calls. If it has no recursive calls, we can show that
it must return if we can show that all the loop conditions must terminate.
So the code
for(i=0;i<N;i++)
abswer += x[i];
must terminate if we can show that i and N are no corrupted and i cannot
wrap before it reaches N.
The code
while(ptr)
{
answer += ptr->x;
ptr = ptr->next;
}
will be in an infinite loop is ptr is a circular list.
If the list is passed, we can prove this function terminates, but only
by stepping up a level, and proving that the list cannot contain a cycle.
>
> Trees are great for climbing - but useless as models of call behaviour
> and structure in programs.
>
We can also prune any if branches that we can prove are not taken.
Typically that situation arises when a constant is passed to a
subroutine. Programmers seldom write redundant ifs, so by looking
at functions in isolation, you can't get this simplification and optimisation.
Now in reality, recursion in C programs is rare, and complex loop conditions
are also pretty rare.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 12:51 +0200 |
| Message-ID | <nkb67r$86t$1@dont-email.me> |
| In reply to | #89695 |
On 21/06/16 11:44, Malcolm McLean wrote:
> On Tuesday, June 21, 2016 at 9:04:03 AM UTC+1, David Brown wrote:
>> On 21/06/16 05:27, Malcolm McLean wrote:
>>> On Tuesday, June 21, 2016 at 3:45:26 AM UTC+1, Richard Heathfield wrote:
>>>> On 21/06/16 03:02, Malcolm McLean wrote:
>>>>
>>>>> The so-called Malcolm call-tree is the structure of a structured
>>>>> program. A tree, with cycles for recursion.
>>>>
>>>> If it has cycles, it's not a tree. If it's not a tree /anyway/, you
>>>> might as well leave functions where they are instead of duplicating them
>>>> all over the place:
>>>>
>>>> A
>>>> |\
>>>> B C
>>>> |/
>>>> D
>>>>
>>>> instead of
>>>>
>>>> A
>>>> |\
>>>> B C
>>>> | \
>>>> D D
>>>>
>>> Yes, it's not a huge point.
>>
>> It is /exactly/ the point. The former is a graph (a directed graph),
>> the later is a tree made by replicating nodes on the graph. The graph
>> is a better model for all but the simplest of programs, precisely
>> because it avoids duplication, and because it is a more general
>> structure. In particular, it also supports conditionals in a practical
>> way (as Richard showed), as well as loops /and/ recursion. Recursion
>> leads to cycles in the directed graph, which spoils some analytical
>> properties - but it allows other sorts of analysis (such as proof by
>> induction).
>>
>> The tree only really makes sense if, in the words of the great Jerry
>> Stuckle, the biggest program you write is "Hello, world".
>>
>>> Sometimes the former graph makes more sense.
>>
>> The former graph almost always makes more sense.
>>
>>>
>>> Not if D takes a function pointer, however. If D takes
>>> a function pointer which is E in B a F in C, the second graph
>>> looks like
>>>
>>> A
>>> | \
>>> B C
>>> | \
>>> D D
>>> | \
>>> E F
>>>
>>> and we know that F is only called once, and always from C.
>>
>> Function pointers /always/ make it harder to follow the call structure
>> of a program. It makes sense to avoid them, or at least limit them or
>> constrain them in some way (such as C++ virtual functions) if you want
>> to generate call graphs or do other analysis on your code.
>>
> The property that all D nodes are the same breaks if D takes and calls
> a function pointer. So yes, they complicate things. The tree makes
> that obvious.
In this particular rare situation where you /know/ that B calls D in a
way that causes it to call E but not F, and that C calls D in a way that
causes it to call F but not E, /then/ the tree makes things obvious.
But it is a highly unusual situation. In virtually all cases,
duplicating D just makes things confusing rather than helping.
>>
>> And yes, sometimes it would make sense to duplicate the node D in a case
>> like this (the alternative is both E and F coming out of D):
>>
>> A
>> |\
>> B C
>> |/
>> D
>> |\
>> E F
>>
>> But such situations are the exception, not the common case.
>>
> With that graph, E is reachable from C.
> It's not "wrong", it's showing a structure which exists, but it's not
> keeping all properties we might desire.
Here in the real world, with actual programs designed to solve real
problems, conditionals of some sort are common practice. Whether this
is done by function pointers or an "if" statement, you are going to get
functions that sometimes call one function, sometimes call another. If
that breaks "properties we might desire", then your desires are unrealistic.
>>
>>>
>>> We can't ban both loops and recursion, unfortunately. We have
>>> to accept the problem somewhere.
>>
>> Loops and recursions are not "problems" - if they don't fit well with
>> your particular ideas of program structure or models, then it is your
>> ideas and models that are the problem. Without loops and recursion (or
>> some equivalent constructs), you can't do anything worthwhile in your
>> programming. Your insistence that everything should look like a tree
>> without cycles (and all fitting on one page, according to your earlier
>> posts) is an artificial and unrealistic constraint. Yes, it is easier
>> to analyse a nice clean tree - but it does not match reality. It's like
>> the physicist who wants to make milk production more efficient, and
>> starts off with "consider a spherical cow...".
>>
> No, you can't abolish the halting problem simply by structuring your
> program.
Who is concerned with the halting problem? That has nothing to do with
the discussion here.
> But we can show that a structured program must return if it has no
> loops or recursive calls. If it has no recursive calls, we can show that
> it must return if we can show that all the loop conditions must terminate.
If you want to prove that a function terminates within a finite time,
you have to prove that all its parts terminate in a finite time. Loops
and recursions are normal parts of that - and you need to prove that
these terminate.
Structure and structured programming has nothing to do with this, other
than to say it is easier to reason about a program's termination if the
code is well structured. But there is nothing about structured
programming that means that a function will definitely terminate (most
of the code I write is quite structured, and most of it never
terminates). And unstructured programs can also terminate, and it can
often be just as easy to prove that they terminate.
>
> So the code
>
> for(i=0;i<N;i++)
> abswer += x[i];
>
> must terminate if we can show that i and N are no corrupted and i cannot
> wrap before it reaches N.
Yes - but that is not because the code is structured, and certainly not
because you can turn it into a tree.
The code:
for (int i = 0; i < N; i++) {
answer += x[i];
if (answer > 1000) return;
}
is unstructured (by most definitions), because of the extra "return" in
the middle. Yet it will terminate at least as often as your structured
code, and it is just as easy to see or prove.
>
> The code
>
> while(ptr)
> {
> answer += ptr->x;
> ptr = ptr->next;
> }
>
> will be in an infinite loop is ptr is a circular list.
True (apart from the typos).
>
> If the list is passed, we can prove this function terminates, but only
> by stepping up a level, and proving that the list cannot contain a cycle.
All this has nothing to do with structured or unstructured programming,
or trees or graphs. Determining if a program terminates or not is
completely unrelated.
What will be your next argument? That all data structures can be
represented as structs or arrays because that gives you nice properties
such as guaranteed no memory leaks? Let's just ignore those messy
programs with "pointers", because they break the "desired properties" of
the structures - and anyway, just like loops and recursion, people don't
really use them.
>>
>> Trees are great for climbing - but useless as models of call behaviour
>> and structure in programs.
>>
> We can also prune any if branches that we can prove are not taken.
> Typically that situation arises when a constant is passed to a
> subroutine. Programmers seldom write redundant ifs, so by looking
> at functions in isolation, you can't get this simplification and optimisation.
>
> Now in reality, recursion in C programs is rare, and complex loop conditions
> are also pretty rare.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-06-21 10:14 -0500 |
| Message-ID | <nkblco$t42$1@dont-email.me> |
| In reply to | #89694 |
David Brown wrote: > On 21/06/16 05:27, Malcolm McLean wrote: <snip> > > Function pointers /always/ make it harder to follow the call > structure of a program. Not in the real world. Tables relying on function pointers will frequently make things easier to understand. In order to scale programs past a certain size, it becomes necessary to "go meta" and indirection is just how that's done, unless you want to resort to C++ style templates or some other analogous mechanism. I predict that 20 years from now, all the "meta" that's currently in style will be gone and largely unmourned, and that 'C' code with function pointers will still be with us. IMO, *the* technology for the management of complexity is still the finite state machine. That's closer to being "function pointer-ey" than it is "call tree-ey". The problem with any discipline that requires a certain academic footing to approach ( and it's arguable whether CS is even one of those even if I think it is[1] ) is that the class bell has to ring some time and things you learn that aren't there because they're fit to print but rather print to fit poison us against things which may be more appropriate. [1] there are legions of people writing software that don't really need to be all that conversant with say, Turing nor Godel or even von Neumann. > It makes sense to avoid them, or at least limit them or constrain > them in some way (such as C++ virtual functions) if you want to > generate call graphs or do other analysis on your code. > Call trees are an attempt to make something that is dynamic static. <snip> > > Trees are great for climbing - but useless as models of call > behaviour and structure in programs. > > +1 -- Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web