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 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-17 14:16 +0100 |
| Message-ID | <nk0t86$cl0$1@dont-email.me> |
| In reply to | #89399 |
On 17/06/16 13:29, Malcolm McLean wrote: > On Friday, June 17, 2016 at 1:13:47 PM UTC+1, Martin Shobe wrote: >> On 6/17/2016 3:09 AM, Malcolm McLean wrote: >>> On Friday, June 17, 2016 at 6:00:12 AM UTC+1, gwowen wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>>> Are you sure? >>>> >>>> Yes >>>> >>>>> Are you sure that the tree as I have described it is not the >>>>> "structure" of "structured programming"? >>>> >>>> Yes >>>> >>> I noticed you snipped the difficult question. >> >> What's difficult about them? You can find the answers to the question >> about what things structure refers to in the wikipedia article that you >> dismissed as being "mostly history". The other answer should then be >> obvious. >> > Anyone can say "yes" or "no" like an insolent schoolboy. Personally, I wouldn't like to compare Martin Shobe to an insolent schoolboy. > > If you read the article carefully you'll see that the structure of structured > programming is as I described. A tree, if I recall your description correctly. > Blocks containing a single point of entry > and a sigle point of exit, which can be expanded to contain other blocks > with the same characteristics. I'd accept that as a working definition of structured programming, but how do you turn that into a tree? Graph, yes. Tree, no. <snip> > Now if you can't see that, you fundamentally haven't understood what > structured programming is all about. Nor would I like to claim that Martin Shobe doesn't understand structured programming. I think he's got a pretty good grasp, as do most good C programmers. > In fact it's best to think of subroutines as "blocks", specify that a subroutine > shall be sufficiently short to be understood to be correct by human examination, > and forget the flowcharts. That's the way structured programming has > developed. Yes, but whence groweth this mysterious tree of which you speak? -- 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-17 06:32 -0700 |
| Message-ID | <5ae89f2a-c418-4417-b142-e4281eabb4fd@googlegroups.com> |
| In reply to | #89409 |
On Friday, June 17, 2016 at 2:17:01 PM UTC+1, Richard Heathfield wrote: > On 17/06/16 13:29, Malcolm McLean wrote: > > > Blocks containing a single point of entry > > and a sigle point of exit, which can be expanded to contain other blocks > > with the same characteristics. > > I'd accept that as a working definition of structured programming, but > how do you turn that into a tree? Graph, yes. Tree, no. > You get your stencil, and you draw the flow chart. it has to fit on a single page, and the only "action" is a block. A rectangle with the action written in it. Flow always starts at the top of the block, and always comes out of the bottom of the block, going down the page. Conventions, obviously. So a block might say "move space invaders". Great, but how do we do that? We produce another flow chart for the "move space invaders" block. It might loop through each space invader, check for collisions, check for proximity to the player, check the invaders energy level, then go onto "attack", "retreat" or "holding" behaviours. All blocks. Similarly the "attack" behaviour can be flow charted. And so it goes on. So the flow charts are organised in the form of a tree. At the root is the overall game logic. Probably a loop on whilst the player is still alive, move player, move invaders, resolve bullets, display frame. The we can break out "move space invaders" as described. A tree. (Now some low level routines like "take square root" will probably appear more than once. So you can say it's a graph, if you want. Or you can say that those are two separate nodes rather than a link into the same node. I'm taking the latter approach, but it's not strictly necessary, you can do it either way.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-17 15:02 +0100 |
| Message-ID | <nk0vt2$lsu$1@dont-email.me> |
| In reply to | #89412 |
On 17/06/16 14:32, Malcolm McLean wrote: > On Friday, June 17, 2016 at 2:17:01 PM UTC+1, Richard Heathfield wrote: >> On 17/06/16 13:29, Malcolm McLean wrote: >> >>> Blocks containing a single point of entry >>> and a sigle point of exit, which can be expanded to contain other blocks >>> with the same characteristics. >> >> I'd accept that as a working definition of structured programming, but >> how do you turn that into a tree? Graph, yes. Tree, no. >> > You get your stencil, and you draw the flow chart. Now I know you're joking. > it has to fit on a single > page, and the only "action" is a block. A rectangle with the action written > in it. Flow always starts at the top of the block, and always comes out of > the bottom of the block, going down the page. Conventions, obviously. (a) You've just removed iteration as a programming technique; (b) the technique you describe doesn't enforce a tree: A calls B and C. B and C both call D. A / \ B C \ / D Graph, not tree. > So a block might say "move space invaders". Great, but how do we do that? > > We produce another flow chart for the "move space invaders" block. It > might loop through each space invader, You can't. You're not allowed to redirect the flow up the page, remember? > So the flow charts are organised in the form of a tree. No, a graph. See above, but now pretend that A-D are flowcharts rather than blocks. > (Now some low level routines like "take square root" will probably appear more > than once. So you can say it's a graph, if you want. That's because it's a graph. > Or you can say that > those are two separate nodes rather than a link into the same node. Unnecessary node duplication. > I'm > taking the latter approach, but it's not strictly necessary, you can do it either > way.) And when you do it the sensible way, you get a graph. When you do it the tree way, you're either duplicating code all over the place, or your diagram is lying to you. -- 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-17 07:45 -0700 |
| Message-ID | <19817c07-5520-4ae5-b834-4f9194153ec6@googlegroups.com> |
| In reply to | #89418 |
On Friday, June 17, 2016 at 3:02:16 PM UTC+1, Richard Heathfield wrote: > On 17/06/16 14:32, Malcolm McLean wrote: > > On Friday, June 17, 2016 at 2:17:01 PM UTC+1, Richard Heathfield wrote: > >> On 17/06/16 13:29, Malcolm McLean wrote: > >> > >>> Blocks containing a single point of entry > >>> and a sigle point of exit, which can be expanded to contain other blocks > >>> with the same characteristics. > >> > >> I'd accept that as a working definition of structured programming, but > >> how do you turn that into a tree? Graph, yes. Tree, no. > >> > > You get your stencil, and you draw the flow chart. > > Now I know you're joking. > > > it has to fit on a single > > page, and the only "action" is a block. A rectangle with the action written > > in it. Flow always starts at the top of the block, and always comes out of > > the bottom of the block, going down the page. Conventions, obviously. > > (a) You've just removed iteration as a programming technique; > (b) the technique you describe doesn't enforce a tree: > > A calls B and C. B and C both call D. > > A > / \ > B C > \ / > D > > Graph, not tree. > > > So a block might say "move space invaders". Great, but how do we do that? > > > > We produce another flow chart for the "move space invaders" block. It > > might loop through each space invader, > > You can't. You're not allowed to redirect the flow up the page, remember? > > > So the flow charts are organised in the form of a tree. > > No, a graph. See above, but now pretend that A-D are flowcharts rather > than blocks. > So you need two copies of D. A tree can have branches that are constrained to be identical to another branch. It doesn't cease to be a tree. We can have two square root branches which will be identical, but if we ask, "how did we get here" the answers are different, there's a different path from tip back to root. > > And when you do it the sensible way, you get a graph. When you do it the > tree way, you're either duplicating code all over the place, or your > diagram is lying to you. > You don't need to duplicate code. But you can if you want. In fact I often do, I often repeat trivial functions like "mystrdup", making them static of course, to avoid creating cross dependencies just for that trivial functionality. Structured programming doesn't capture that. It doesn't address every issue to do with program structure (as the term is used, you can of course say that this is part of the program structure and so a "structured programming" issue in a sense). Secondly, though I've said that named subroutines are the blocks, that's only true of modern structured programming. It's not strictly necessary. You can write structured programs making C curly brace blocks the blocks. Then it must be viewed as a tree, C doesn't support references to duplicate blocks.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-17 18:34 +0100 |
| Message-ID | <nk1cb8$50d$1@dont-email.me> |
| In reply to | #89422 |
On 17/06/16 15:45, Malcolm McLean wrote: > On Friday, June 17, 2016 at 3:02:16 PM UTC+1, Richard Heathfield wrote: <snip> >> >> (a) You've just removed iteration as a programming technique; >> (b) the technique you describe doesn't enforce a tree: >> >> A calls B and C. B and C both call D. >> >> A >> / \ >> B C >> \ / >> D >> >> Graph, not tree. >> <snip> >> >>> So the flow charts are organised in the form of a tree. >> >> No, a graph. See above, but now pretend that A-D are flowcharts rather >> than blocks. >> > So you need two copies of D. Malcolm, you /must/ know this is insane. You /must/. Is it 1st April already? -- 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-06-18 18:06 +0100 |
| Message-ID | <87lh22e8ak.fsf@gmail.com> |
| In reply to | #89437 |
Richard Heathfield <rjh@cpax.org.uk> writes: >>> No, a graph. See above, but now pretend that A-D are flowcharts rather >>> than blocks. >>> >> So you need two copies of D. > > Malcolm, you /must/ know this is insane. You /must/. You give him far too much credit.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-06-18 12:06 +0100 |
| Message-ID | <87mvmivjr7.fsf@gmail.com> |
| In reply to | #89399 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > Anyone can say "yes" or "no" like an insolent schoolboy. Careful with the handbag, Malc. > If you read the article carefully you'll see that the structure of > structured programming is as I described. I did. It didn't.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-17 21:49 +0100 |
| Message-ID | <87shwbtuas.fsf@bsb.me.uk> |
| In reply to | #89356 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, June 16, 2016 at 11:10:57 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> <snip> >> > This tree is the central structure that makes structured programming >> > structured. >> >> No it isn't. Anyone who wants to find out what are the central features >> of structured programming really are should read what the experts say >> about it. You could do worse than start with the inventor of the term: >> >> "Structured Programming", O. Dahl, Edsger Dijkstra, C. A. R. Hoare, >> available in various editions. Originally published in 1972. >> > Are you sure? > Are you sure that the tree as I have described it is not the > "structure" of "structured programming"? You don't really care do you? That sounds like a rhetorical question. But if you want an answer, yes, I am about as sure as I can reasonably. I am reasonably well-educated in the field and I've read many books and papers on the subject. > What other thing would you say the "structure" refers to? How > does it differ from the tree of functions or "blocks" that I > have described? The most striking feature is the you invented this tree to show that recursion is unstructured or, at least in some significant way, antithetical to the structured approach, but nearly every author I've read on the subject includes recursive programs as examples of well-structured programs, and none at all exclude recursion for being antithetical to the notion. Clearly being "structured" means something else for all these authors. A fuller discussion would require pinning down what you are claiming but that appears to be shifting ground. Where you once said that making such a tree using blocks rather than subroutines was a bad idea, you are now saying that it's central. Where you once claimed that the tree must be (roughly) balanced you no longer seem to consider that important. (Good thing too since I don't think it can't be if you need to starting talking about blocks as well as subroutines.) But worst of all are the dreaded scare quotes around "blocks". Goodness knows what you mean by a "block". By the way, do you think structured programming is a good idea? I ask because you sometimes urge the use of what I think of as unstructured code (in the usual sense, that is) as being the best option for some some very common situations in C -- resource clean-up on error for example. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 15:35 -0700 |
| Message-ID | <f19dd099-f946-4ffd-ae8f-fd7366f17ced@googlegroups.com> |
| In reply to | #89456 |
On Friday, June 17, 2016 at 9:49:43 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Are you sure? > > Are you sure that the tree as I have described it is not the > > "structure" of "structured programming"? > > You don't really care do you? That sounds like a rhetorical question. > But if you want an answer, yes, I am about as sure as I can reasonably. > I am reasonably well-educated in the field and I've read many books and > papers on the subject. > So you haven't understood what you've read. > > > What other thing would you say the "structure" refers to? How > > does it differ from the tree of functions or "blocks" that I > > have described? > > The most striking feature is the you invented this tree to show that > recursion is unstructured or, at least in some significant way, > antithetical to the structured approach, but nearly every author I've > read on the subject includes recursive programs as examples of > well-structured programs, and none at all exclude recursion for being > antithetical to the notion. Clearly being "structured" means something > else for all these authors. > No, I did not invent structured programming, I did not invent the idea of "blocks" with one point of entry and one point of exit, I did not invent the idea that such blocks nest. I did not invent subroutines. I was maybe the first to point out that recursion breaks or strains the paradigm, but I did not invent the notion of nested blocks. The "tree" is not my idea. I'm not the first person to point out that a structured program with its subroutines forms a tree. People use "structured" to mean "well organised" which is the natural English meaning of the term. Maybe they don't understand what structured programming is, maybe they just use the term in two senses. > > A fuller discussion would require pinning down what you are claiming but > that appears to be shifting ground. Where you once said that making > such a tree using blocks rather than subroutines was a bad idea, you are > now saying that it's central. Where you once claimed that the tree must > be (roughly) balanced you no longer seem to consider that important. > (Good thing too since I don't think it can't be if you need to starting > talking about blocks as well as subroutines.) But worst of all are the > dreaded scare quotes around "blocks". Goodness knows what you mean by a > "block". > To clarify, you can use curly brace blocks in the C sense as your "blocks" in the structured programming sense and write a structured program that way. Almost no-one does so. The main block unit is the named subroutine. That's how structured programming has developed. > > By the way, do you think structured programming is a good idea? I ask > because you sometimes urge the use of what I think of as unstructured > code (in the usual sense, that is) as being the best option for some > some very common situations in C -- resource clean-up on error for > example. > Yes, there's a superstitious avoidance of "goto". Strictly, function internals should also be structured and C curly brace blocks should also be structured programming "blocks" (one point of entry, one point of exit). I don't consider that to be very important, we simply say that functions shall be short and therefore human-understandable. And that's not just my own eccentric opinion. The flow charts have been abandoned. I was taught to flow chart my functions, but no one does so any more. I've lost the plastic stencil and you a rarely see them on sale now. Blocks in modern structured programming are subroutines, that's how programmers think of their designs, that's the main form of code organisation. Error handling was a known weakness of the paradigm anyway.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-18 02:18 +0100 |
| Message-ID | <87fusbthuc.fsf@bsb.me.uk> |
| In reply to | #89467 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, June 17, 2016 at 9:49:43 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > Are you sure? >> > Are you sure that the tree as I have described it is not the >> > "structure" of "structured programming"? >> >> You don't really care do you? That sounds like a rhetorical question. >> But if you want an answer, yes, I am about as sure as I can reasonably. >> I am reasonably well-educated in the field and I've read many books and >> papers on the subject. >> > So you haven't understood what you've read. I thought there was not much point in my answering that question! >> > What other thing would you say the "structure" refers to? How >> > does it differ from the tree of functions or "blocks" that I >> > have described? >> >> The most striking feature is the you invented this tree to show that >> recursion is unstructured or, at least in some significant way, >> antithetical to the structured approach, but nearly every author I've >> read on the subject includes recursive programs as examples of >> well-structured programs, and none at all exclude recursion for being >> antithetical to the notion. Clearly being "structured" means something >> else for all these authors. >> > No, I did not invent structured programming, I did not invent > the idea of "blocks" with one point of entry and one point of exit, > I did not invent the idea that such blocks nest. I did not invent > subroutines. Where does all that come from? I never said you invented any of those things. The only thing I think you invented was the tree that is neither the call graph nor the calling context tree. > I was maybe the first to point out that recursion breaks or > strains the paradigm, Ah, so you are not re-defining the term at all. You are just pointing out that Wirth and Dijkstra and Hoare and all the others did not see that they were wrong to admit recursive programs into what they themselves had defined as being structured programs. Surely there's a paper in that? There are lots of academics like me who believed that Wirth and Dijkstra and Hoare and the others had understood the idea they were promoting. > but I did not invent the notion of > nested blocks. Again, I never said you did. > The "tree" is not my idea. I'm not the first > person to point out that a structured program with its subroutines > forms a tree. But you are the first person to mangle this trivial idea. You insist on a tree, so you must reject the usual call graph, but you also reject the calling context tree since that is a tree even for recursive programs. Can you site anyone who defined the tree as you do? (I know, I'm asking for citation, but if you write that paper you'll need one anyway since the idea is not yours.) (You've also mangled it by claiming that calls to functions via pointer parameters can't be represented, but that notion seems to have died without ever being resolved.) <snip> >> By the way, do you think structured programming is a good idea? I ask >> because you sometimes urge the use of what I think of as unstructured >> code (in the usual sense, that is) as being the best option for some >> some very common situations in C -- resource clean-up on error for >> example. >> > Yes, there's a superstitious avoidance of "goto". I don't think you've understood authors like Dijkstra and Hoare if you think that avoiding jumps from multiple point into some piece of code is simply superstition. All those authors may be wrong, of course, but their arguments are anything but superstitious. To refute them you'd have to address them. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 19:00 -0700 |
| Message-ID | <03802ca2-ed43-4588-98f3-b442935acbd6@googlegroups.com> |
| In reply to | #89484 |
On Saturday, June 18, 2016 at 2:18:48 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > No, I did not invent structured programming, I did not invent > > the idea of "blocks" with one point of entry and one point of exit, > > I did not invent the idea that such blocks nest. I did not invent > > subroutines. > > Where does all that come from? I never said you invented any of those > things. The only thing I think you invented was the tree that is > neither the call graph nor the calling context tree. > A block has a single point of entry and a single point of exit, but is not necessarily a linear list of instructions. So structured programming says that, in that situation, it is to be broken down, and the result is a flow chart containing more blocks. So a tree naturally results. It's not my invention. It emerges as a consequence of the rules. That is why languages which support structured programming concepts usually have indentation or brackets to denote levels of block nesting. That is a tree. That is the "structure" to which the "structure" in "structured programming" refers. However subroutines are also blocks. > > I was maybe the first to point out that recursion breaks or > > strains the paradigm, > > Ah, so you are not re-defining the term at all. You are just pointing > out that Wirth and Dijkstra and Hoare and all the others did not see > that they were wrong to admit recursive programs into what they > themselves had defined as being structured programs. > I'm not saying they were wrong. I'm saying that recursive functions break the paradigm. The "tree" disappears. It gains a cycle. It is no longer a tree. So a desirable characteristic has been lost. That is not the same thing as saying that recursion should not have been allowed. > > Surely there's a paper in that? There are lots of academics like me who > believed that Wirth and Dijkstra and Hoare and the others had understood > the idea they were promoting. > It's possible they didn't realise that allowing recursion was introducing undesireable characteristics into programs, such as the inability to easily determine a limit on stack usage. But if so it was quickly spotted. I can't claim to be the first person to point that out. But again, we wouldn't normally cite the first person to realise that problem. > > > but I did not invent the notion of > > nested blocks. > > Again, I never said you did. > > > The "tree" is not my idea. I'm not the first > > person to point out that a structured program with its subroutines > > forms a tree. > > But you are the first person to mangle this trivial idea. You insist on > a tree, so you must reject the usual call graph, but you also reject the > calling context tree since that is a tree even for recursive programs. > Can you site anyone who defined the tree as you do? (I know, I'm asking > for citation, but if you write that paper you'll need one anyway since > the idea is not yours.) > If you have never seen a program drawn out as a tree I suppose you would ask for a cite. Generally we don't cite information such as that. I've no idea who was the first person to recognise that if blocks nest then a tree results. > > (You've also mangled it by claiming that calls to functions via pointer > parameters can't be represented, but that notion seems to have died > without ever being resolved.) > The tree disappears if the pointer parameter is "dynamically bound". > > I don't think you've understood authors like Dijkstra and Hoare if you > think that avoiding jumps from multiple point into some piece of code is > simply superstition. All those authors may be wrong, of course, but > their arguments are anything but superstitious. To refute them you'd > have to address them. > It depends on the size of the block of code. The superstition is to think that by adhering to a rule in an absolutely rigid way, "merit" attaches to the result. It's a bit like a teetotaler, reasonably, refusing to drink whisky on the grounds of its addictiveness, then refusing to eat potato crisps which contain traces of alcohol used to solubise the flavourings.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 22:36 -0400 |
| Message-ID | <nk2c44$am7$1@dont-email.me> |
| In reply to | #89490 |
On 6/17/2016 10:00 PM, Malcolm McLean wrote:
> On Saturday, June 18, 2016 at 2:18:48 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> No, I did not invent structured programming, I did not invent
>>> the idea of "blocks" with one point of entry and one point of exit,
>>> I did not invent the idea that such blocks nest. I did not invent
>>> subroutines.
>>
>> Where does all that come from? I never said you invented any of those
>> things. The only thing I think you invented was the tree that is
>> neither the call graph nor the calling context tree.
>>
> A block has a single point of entry and a single point of exit,
The `switch' statement demonstrates both assertions false.
Consider also one-block functions like
int compare(const void *pp, const void *qq) {
const double p = *(const int*)pp;
const double q = *(const int*)qq;
if (p < q)
return -1;
else if (p > q)
return 1;
return 0;
}
Three exits. Count them if you doubt me.
> However subroutines are also blocks.
Not sure what you mean by "subroutine," since you're using your
own private nomenclature. In C, though, a "function" is a construct
consisting of an "introducer" (my own term; you're in no position
to object) plus a block that may in turn contain further blocks.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-18 20:28 +0000 |
| Message-ID | <5765ade6.30685687@news.xs4all.nl> |
| In reply to | #89490 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > A block has a single point of entry and a single point of exit, > but is not necessarily a linear list of instructions. So structured > programming says that, in that situation, it is to be broken > down, and the result is a flow chart containing more blocks. > > So a tree naturally results. This does not follow. A _graph_ naturally results. Obviously - you don't even need structured programming for that. A tree only results if no two functions ever call the same function. Unless you're not describing the call graph but the list of stack frames - in which case, a tree naturally results _even with recursion_; and here, too, un-structured programming doesn't change anything. > The superstition is to think that by adhering to a rule in an absolutely > rigid way, "merit" attaches to the result. What, like the rule "don't use recursion"? > It's a bit like a teetotaler, reasonably, refusing to drink whisky on > the grounds of its addictiveness, then refusing to eat potato crisps > which contain traces of alcohol used to solubise the flavourings. I see you've never had to deal with alcoholics. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-19 03:00 +0100 |
| Message-ID | <87lh22rl93.fsf@bsb.me.uk> |
| In reply to | #89490 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, June 18, 2016 at 2:18:48 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > No, I did not invent structured programming, I did not invent >> > the idea of "blocks" with one point of entry and one point of exit, >> > I did not invent the idea that such blocks nest. I did not invent >> > subroutines. >> >> Where does all that come from? I never said you invented any of those >> things. The only thing I think you invented was the tree that is >> neither the call graph nor the calling context tree. >> > A block has a single point of entry and a single point of exit, > but is not necessarily a linear list of instructions. So structured > programming says that, in that situation, it is to be broken > down, and the result is a flow chart containing more blocks. The sand has shifted. You started by talking about subroutines, going so far as to say that the doing the same for blocks was wrong. Now it's blocks, blocks, blocks and subroutines are an afterthought. > So a tree naturally results. Nor *a* tree -- several different trees and more than one graph depending on how you define them. I say you made up *your* definition (the one that should, apparently, only be applied to subroutines) for the purpose of saying "structured programs have no loops in the Malcolm-class-tree so recursion is not structured". You went so far as to say that this was not your idea. Where is your citation for someone else using the same Malcolm-call-tree? > It's not my invention. It emerges as a consequence of the rules. Your tree -- the subroutine one -- emerges from the rule you made up to get the entirely arbitrary conclusion you wanted. I claims that no one else has made up such a tree -- of subroutines calls remember -- or you would be able to cite and example. > That is why languages which support structured programming > concepts usually have indentation or brackets to denote levels > of block nesting. That is a tree. That is the "structure" to > which the "structure" in "structured programming" refers. > > However subroutines are also blocks. Your tree -- the subroutine one you made up -- has a crucial property that is not applicable to blocks. >> > I was maybe the first to point out that recursion breaks or >> > strains the paradigm, >> >> Ah, so you are not re-defining the term at all. You are just pointing >> out that Wirth and Dijkstra and Hoare and all the others did not see >> that they were wrong to admit recursive programs into what they >> themselves had defined as being structured programs. >> > I'm not saying they were wrong. > I'm saying that recursive functions break the paradigm. I did not say you said they wree wrong. I said you are saying they were wrong not to see that recursion was antithetical to structured programming. And you are saying that they missed it. > The "tree" > disappears. It gains a cycle. The Malcolm-call-tree that you made up has a cycle. It's specially constructed so that a recursive call it treated differently to differently to a non-recursive call. The usual call graph often has cycles and the dynamic context call tree never does. To get round the Malcolm-call-tree's nodes represent distinct call instances except when the the call is recursive. > It is no longer a tree. So a > desirable characteristic has been lost. That is not the same > thing as saying that recursion should not have been allowed. Nonsense. There is no reason to believe that the Malcolm-call-tree has any significance other than to get you the result you want. Cite anyone else who defines a call tree like you do and who claim that a cycle represents anything other than an artefact of the construction. >> Surely there's a paper in that? There are lots of academics like me who >> believed that Wirth and Dijkstra and Hoare and the others had understood >> the idea they were promoting. >> > It's possible they didn't realise that allowing recursion was introducing > undesireable characteristics into programs, such as the inability > to easily determine a limit on stack usage. I hope you are aware that you can't easily determine a limit on stack usage even in the absence of recursion. Some programming languages help, but structured programming is done in many languages. Anyway, the authors in question are well aware that you can not determine a limit on the space needed for activation records just as they are aware that you can't do that for other storage that might be required. They are, amongst other things, designers and implementors of programming languages and (at least Dijkstra and Hoare) have written about how to implement function calls safely and efficiently. > But if so it was quickly > spotted. I can't claim to be the first person to point that out. The sand is starting to shift again. Of course you are not the first to point that out. It is a trivially obvious observation that applies to non-recursive programs as well. It can not have escaped anyone who implements high-level programming languages. The point is that you claim to be the first to point out that recursion is unstructured which is something else entirely. > But again, we wouldn't normally cite the first person to realise > that problem. You claim the Malcolm-call-tree is not your own invention. Either cite where you've seen it before or at least say that you can't. >> > but I did not invent the notion of >> > nested blocks. >> >> Again, I never said you did. >> >> > The "tree" is not my idea. I'm not the first >> > person to point out that a structured program with its subroutines >> > forms a tree. >> >> But you are the first person to mangle this trivial idea. You insist on >> a tree, so you must reject the usual call graph, but you also reject the >> calling context tree since that is a tree even for recursive programs. >> Can you site anyone who defined the tree as you do? (I know, I'm asking >> for citation, but if you write that paper you'll need one anyway since >> the idea is not yours.) >> > If you have never seen a program drawn out as a tree I suppose you > would ask for a cite. Generally we don't cite information such > as that. I've no idea who was the first person to recognise that > if blocks nest then a tree results. Don't play dumb. I am asking for a cite for the Malcolm-call-tree -- the one that is not the usual call graph (because that has cycles) and is not the dynamic context call tree (because that does not have them even for recursive calls). I'm asking for where you've seen the construction that, by simply treating recursive calls specially, has exactly the property you want -- cycles only in recursive programs. >> (You've also mangled it by claiming that calls to functions via pointer >> parameters can't be represented, but that notion seems to have died >> without ever being resolved.) >> > The tree disappears if the pointer parameter is "dynamically bound". I showed how to write a Malcolm-call-tree for the program wher you said it coculd not be done. That would be where to explain why I was wong. You just cut that without comment. The Malcolm-call-tree may well have properties I've missed, but C's function pointer parameters are trivial t handle from what I've understood so far. If you like, re-instate the example and explain why it can't be done (or reply to that part of that post of mine). >> I don't think you've understood authors like Dijkstra and Hoare if you >> think that avoiding jumps from multiple point into some piece of code is >> simply superstition. All those authors may be wrong, of course, but >> their arguments are anything but superstitious. To refute them you'd >> have to address them. >> > It depends on the size of the block of code. > The superstition is to think that by adhering to a rule in an absolutely > rigid way, "merit" attaches to the result. It's a bit like a teetotaler, > reasonably, refusing to drink whisky on the grounds of its > addictiveness, then refusing to eat potato crisps which contain > traces of alcohol used to solubise the flavourings. As said, you'd have to address the argument they make, not simply state, again and again, that it's a fetish. It would start by taking an actual objection and refuting it. Then repeating that for all of them. As I say, that might be possible, at least for the cases of goto that you champion so it may be worth a try. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-19 03:31 +0100 |
| Message-ID | <87a8ihsyct.fsf@bsb.me.uk> |
| In reply to | #89595 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: <snip> > The usual call graph often has cycles and the dynamic context call tree > never does. Sorry, I meant the usual call graph is often not a tree and the dynamic context call tree never has cycles. <snip> > ... I am asking for a cite for the Malcolm-call-tree -- > the one that is not the usual call graph (because that has cycles) and > is not the dynamic context call tree (because that does not have them > even for recursive calls). I'm asking for where you've seen the > construction that, by simply treating recursive calls specially, has > exactly the property you want -- cycles only in recursive programs. Ditto here. The usual call graph is not a tree (as you desire) and the dynamic context call tree has no cycles (even with recursion). Only your construction gives you what you want -- cycles only in recursive programs. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 20:00 -0700 |
| Message-ID | <31336500-cf21-428d-9937-d11dc5f9e5f3@googlegroups.com> |
| In reply to | #89595 |
On Sunday, June 19, 2016 at 3:00:17 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > The sand has shifted. You started by talking about subroutines, going > so far as to say that the doing the same for blocks was wrong. Now it's > blocks, blocks, blocks and subroutines are an afterthought. > A subroutine is a block, in the structured programming sense, as long as it adheres to a few rules, which are normally kept. It's also the main "block" structure. Structured programming is mainly about that. > > > So a tree naturally results. > > Nor *a* tree -- several different trees and more than one graph > depending on how you define them. I say you made up *your* definition > (the one that should, apparently, only be applied to subroutines) for > the purpose of saying "structured programs have no loops in the > Malcolm-class-tree so recursion is not structured". You went so far as > to say that this was not your idea. Where is your citation for someone > else using the same Malcolm-call-tree? > Blocks contain other blocks, plus a few control structures. That is the central idea of structured programming. Recursion is where a bloc contains itself. It breaks the "tree" structure. So structured programming is not a tree, if you allow recursion. Recursion is therefore the exceptional case. A mistake, if you insist, though I didn't actually say that. Blocks cannot be recursive unless they are also subroutines, at least in any programming language I have seen. So if we are talking about recursion and structured programming, we can ignore blocks which are not subroutines. They're irrelevant. Unless you need to go right back to basics. > > It's not my invention. It emerges as a consequence of the rules. > > Your tree -- the subroutine one -- emerges from the rule you made up to > get the entirely arbitrary conclusion you wanted. I claims that no one > else has made up such a tree -- of subroutines calls remember -- or you > would be able to cite and example. > Thank you for saying structured programming is my invention. But I can't really claim it. > > > I'm not saying they were wrong. > > I'm saying that recursive functions break the paradigm. > > I did not say you said they wree wrong. I said you are saying they were > wrong not to see that recursion was antithetical to structured > programming. And you are saying that they missed it. > OK, so we disagree. Allowing recursion breaks some nice properties that structured programs written without recursion have. You disagree. But you seem to be totally focused on denying that structured programs form a tree (Unless they are recursive), and then not realising that the "tree", which you deny exists, is the property that recursion breaks. That's what makes recursion the fly in the ointment. > > The Malcolm-call-tree that you made up has a cycle. It's specially > constructed so that a recursive call it treated differently to > differently to a non-recursive call. > > The usual call graph often has cycles and the dynamic context call tree > never does. To get round the Malcolm-call-tree's nodes represent > distinct call instances except when the the call is recursive. > Exactly. Except the Malcolm-call-tree is a completely natural structure which anyone could spot instantly as arising from subroutines (or blocks, we really shouldn't have to go into that, but everyone seems to insist). > > > It is no longer a tree. So a > > desirable characteristic has been lost. That is not the same > > thing as saying that recursion should not have been allowed. > > Nonsense. There is no reason to believe that the Malcolm-call-tree has > any significance other than to get you the result you want. Cite anyone > else who defines a call tree like you do and who claim that a cycle > represents anything other than an artefact of the construction. > Anyone who has pointed out that it's important to pass a "depth" parameter to recursive routines if you are afraid of blowing the stack. I certainly wasn't the first person to make that observation. But since it's so basic, you can't expect a cite. > > I hope you are aware that you can't easily determine a limit on stack > usage even in the absence of recursion. Some programming languages > help, but structured programming is done in many languages. > You deny that the so called Malcolm-call tree exists, then wonder why one of its properties doesn't exist. > > Anyway, the authors in question are well aware that you can not > determine a limit on the space needed for activation records just as > they are aware that you can't do that for other storage that might be > required. They are, amongst other things, designers and implementors of > programming languages and (at least Dijkstra and Hoare) have written > about how to implement function calls safely and efficiently. > KISS. Most programs perform a subset of possible calculations, and can be written without recursion or unbounded buffers. > > > But if so it was quickly > > spotted. I can't claim to be the first person to point that out. > > The sand is starting to shift again. Of course you are not the first to > point that out. It is a trivially obvious observation that applies to > non-recursive programs as well. It can not have escaped anyone who > implements high-level programming languages. The point is that you > claim to be the first to point out that recursion is unstructured which > is something else entirely. > > You claim the Malcolm-call-tree is not your own invention. Either cite > where you've seen it before or at least say that you can't. > It's a structure that arises from any program written according to the rules I have given, which I refer to as "structured programming", with the proviso that recursion is excluded. Now if I invented all this, I'm flattered, but my understanding is that I can't claim it, > > Don't play dumb. I am asking for a cite for the Malcolm-call-tree -- > the one that is not the usual call graph (because that has cycles) and > is not the dynamic context call tree (because that does not have them > even for recursive calls). I'm asking for where you've seen the > construction that, by simply treating recursive calls specially, has > exactly the property you want -- cycles only in recursive programs. > Recursion is a cycle in the Malcolm-call-tree. > > I showed how to write a Malcolm-call-tree for the program wher you said > it coculd not be done. That would be where to explain why I was wong. > You just cut that without comment. The Malcolm-call-tree may well have > properties I've missed, but C's function pointer parameters are trivial > t handle from what I've understood so far. If you like, re-instate the > example and explain why it can't be done (or reply to that part of that > post of mine). > If we pass a named function pointer, we still have a Malcolm-call-tree. The subroutine which takes the function pointer and calls it has a leaf which is the subroutine pointed to. The Malcolm-call-tree disappears if the function pointer is "dynamically bound". If we allow the function pointer to take two values, we can say we've got two leaves, one on the control path with function pointer a, one on the path with function pointer b, but then we've got to modify the definition of "block". if we allow more values, we get into a further mess. > > As said, you'd have to address the argument they make, not simply state, > again and again, that it's a fetish. It would start by taking an actual > objection and refuting it. Then repeating that for all of them. As I > say, that might be possible, at least for the cases of goto that you > champion so it may be worth a try. > The case for goto is pretty simple. In structured programming, blocks nest, and have a single point of entry and of exit. So any block can be replaced by any other that has the same effects. So if internally a block is spaghetti code, and not structured according to the rules, that has no effect on the block that contains it (the node above in the Malcolm-call-tree), and it has no effect on the blocks that it calls (the children in the Malcolm call-tree). So there's no real need to avoid goto if the "balanced Malcolm- call-tree with small nodes" property is observed. It's not important in modern structured programming. Only gotos between blocks break the paradigm. It's something which was historically important and is kind of nice in a formal theory sense, but is no longer very important.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-19 15:34 +0100 |
| Message-ID | <87wpllqmbj.fsf@bsb.me.uk> |
| In reply to | #89598 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, June 19, 2016 at 3:00:17 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The sand has shifted. You started by talking about subroutines, going >> so far as to say that the doing the same for blocks was wrong. Now it's >> blocks, blocks, blocks and subroutines are an afterthought. >> > A subroutine is a block, in the structured programming sense, as > long as it adheres to a few rules, which are normally kept. > It's also the main "block" structure. Structured programming is > mainly about that. >> >> > So a tree naturally results. >> >> Nor *a* tree -- several different trees and more than one graph >> depending on how you define them. I say you made up *your* definition >> (the one that should, apparently, only be applied to subroutines) for >> the purpose of saying "structured programs have no loops in the >> Malcolm-class-tree so recursion is not structured". You went so far as >> to say that this was not your idea. Where is your citation for someone >> else using the same Malcolm-call-tree? >> > Blocks contain other blocks, plus a few control structures. > That is the central idea of structured programming. Recursion > is where a bloc contains itself. It breaks the "tree" structure. This is the heart of the matter. Blocks nest and subroutine calls nest, so you get a tree either way. I know of no programming notation in which which a block or a subroutine can contain itself (and you concur). But if you insist on thinking of a subroutine call as a textual replacement one of two things will happen: if you do this dynamically you a finite program with nested blocks. If you do it statically you get an infinite text with nested blocks. No cycles. In order to get that cycle you treat recursive calls differently from all others. When Eric showed you that the call graph of a typical program is not a tree, you explained that *your* call tree has distinct nodes for each call instance. Do you remember that? When I said that you will then get a tree in all cases you brought in the special rule -- recursive call instances are not represented by new nodes but are drawn by making a cycle. Then you decreed that cycles in this Malcolm-call-tree show that recursive programs are not well structured. A summary: (a) All serious authors consider recursive calls to be perfectly valid in structured programs. (b) No one else defines this Malcolm-call-tree (at least you can't cite any examples). Everyone else either talks about the call *graph* or the dynamic call tree which remains a tree even for recursive programs. (c) You should have stuck with the conventional call graph because that is widely used and contains a cycle when the program is recursive, but you decided to insist on talking about a call tree and that needed your special treatment of some calls to get the cycle. Of course you'd still have to explain why a cycle in the graph is anything but a curiosity. (d) We both agree that recursive calls are different. Before they were widely seen as helpful some languages forbade them to permit static allocation of activation records. Unfortunately for your argument the main (early) proponents of structured programming were also amongst the most active in promoting recursive functions. They saw no conflict there. <snip> >> > It's not my invention. It emerges as a consequence of the rules. >> >> Your tree -- the subroutine one -- emerges from the rule you made up to >> get the entirely arbitrary conclusion you wanted. I claims that no one >> else has made up such a tree -- of subroutines calls remember -- or you >> would be able to cite and example. >> > Thank you for saying structured programming is my invention. Seriously? That's the level at which you want to conduct this exchange? > ... You disagree. But you seem to be > totally focused on denying that structured programs form a tree > (Unless they are recursive), and then not realising that the "tree", > which you deny exists, is the property that recursion breaks. Of course your tree exists. I am denying that it has anything to do with structured programming. If it did someone else would have talked about it. The dynamic call tree exists (and is talked about) but that does not suit you purpose because it is always a tree. And the fact that textually replaced subroutine calls are also always nested does not suit ether. That's why you had to invent it. <snip> > ... Except the Malcolm-call-tree is a completely natural > structure which anyone could spot instantly as arising from > subroutines It's almost as natural as the ordinary dynamic call tree. It has only one extra rule that makes a special case out of recursion. <snip> >> You claim the Malcolm-call-tree is not your own invention. Either cite >> where you've seen it before or at least say that you can't. >> > It's a structure that arises from any program written according to > the rules I have given, which I refer to as "structured programming", > with the proviso that recursion is excluded. Now if I invented all > this, I'm flattered, but my understanding is that I can't claim it, If you came by that understand by reading something, please cite it. If not, I'll continue to assume you made it up. I'm not talking about structured programming, that was Dijkstra et al. And I'm not talking the notion of a static call graph or a dynamic call tree -- those are both lost in lost in time. I'm talking about your construct that special-cases recursion. <snip> >> I showed how to write a Malcolm-call-tree for the program wher you said >> it coculd not be done. That would be where to explain why I was wong. >> You just cut that without comment. The Malcolm-call-tree may well have >> properties I've missed, but C's function pointer parameters are trivial >> t handle from what I've understood so far. If you like, re-instate the >> example and explain why it can't be done (or reply to that part of that >> post of mine). >> > If we pass a named function pointer, we still have a Malcolm-call-tree. > The subroutine which takes the function pointer and calls it has a > leaf which is the subroutine pointed to. You appeared to deny that in the past. The example had two calls to qsort with named functions as arguments. > The Malcolm-call-tree disappears if the function pointer is "dynamically > bound". I wonder what that means. I assume the scare quotes mean you don't know exactly what you mean here. Are you referring to dynamic binding as seen in, for example, Lisp? > If we allow the function pointer to take two values, we > can say we've got two leaves, one on the control path with function > pointer a, one on the path with function pointer b, but then we've > got to modify the definition of "block". if we allow more values, > we get into a further mess. So are you pointing out another disagreement with what everyone else calls structured programming? For everyone else not only is recursion OK but function arguments are as well. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 10:20 +0200 |
| Message-ID | <nk0bs7$hta$1@dont-email.me> |
| In reply to | #89284 |
On 16/06/16 17:21, Malcolm McLean wrote: > On Thursday, June 16, 2016 at 3:12:26 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> So your answer (extrapolated from below) is that in your graph the nodes >> are individual calls not named functions: >> >> main >> / \ >> printf print >> \ >> printf >> >> In that case it remains a tree even if the call pattern becomes >> recursive. >> > No, because if we disallow recursive calls and function pointers, then we > can draw the tree simply by looking through the function source and adding > an edge and a child each time a call appears in the source. > The clue is in the name - it is a "call graph", not a "call tree". In a "graph", there can be more than one node leading into a given node, not just one. Recursion leads to cycles in the graph, but that's fine too - graphs can have cycles (though you can do more analysis on an acyclic directed graph than a directed graph that may contain cycles). Function pointers make the graph more complicated, and can hinder static analysis - though often you know enough to draw the possible calls. If you don't know what functions will be called, then you can't draw the complete call graph until run-time. > If we allow recursive calls, either we have to draw a cycle (so we no longer > have a tree), or we have to know how deep the recursion goes at compile > time, which is unlikely. otherwise we can't draw the tree. It is not a call tree, it is a call graph. > > With function pointers, we can still draw the tree if we know the identity > of the function pointer at compile time, though we lose the property > that all nodes with the same function name are identical. if we can't > determined the identity of the function pointer at compile time, we can't > draw the tree. > > This tree is the central structure that makes structured programming structured. Nope. > (You can define nodes as blocks rather than functions, which is a bad idea, > but links nicely with block scope variables thread). >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 02:13 -0700 |
| Message-ID | <4f03dd65-e992-4851-9a85-c82cee04a3a5@googlegroups.com> |
| In reply to | #89371 |
On Friday, June 17, 2016 at 9:20:31 AM UTC+1, David Brown wrote: > On 16/06/16 17:21, Malcolm McLean wrote: > > On Thursday, June 16, 2016 at 3:12:26 PM UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > >> So your answer (extrapolated from below) is that in your graph the nodes > >> are individual calls not named functions: > >> > >> main > >> / \ > >> printf print > >> \ > >> printf > >> > >> In that case it remains a tree even if the call pattern becomes > >> recursive. > >> > > No, because if we disallow recursive calls and function pointers, then we > > can draw the tree simply by looking through the function source and adding > > an edge and a child each time a call appears in the source. > > > > The clue is in the name - it is a "call graph", not a "call tree". In a > "graph", there can be more than one node leading into a given node, not > just one. > I wrote: A structured program consists of a tree of subroutines (functions in C terminology), which is meant to be roughly balanced - you can't turn a list of commands into a structured program by drawing lines every so often and converting the step to a call, and you can't turn a list of commands into a structured program by saying that each command is actually a subroutine (which it often is in a lower level sense). it's got to be roughly balanced, non-degenerate tree. I did not use the term call graph. Other people said "that's a call graph, and Malcolm has it wrong". Now someone can use the wrong or a non-standard word for something, or he can use the right word but describe the entity incorrectly. But he can't do both. If he says "that's a zibra", you may not say "no, you're wrong, it's a "zebra". And you're wrong again. A zebra has black and white stripes, that one has pink stripes".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 11:44 +0200 |
| Message-ID | <nk0gpi$1ef$1@dont-email.me> |
| In reply to | #89377 |
On 17/06/16 11:13, Malcolm McLean wrote: > On Friday, June 17, 2016 at 9:20:31 AM UTC+1, David Brown wrote: >> On 16/06/16 17:21, Malcolm McLean wrote: >>> On Thursday, June 16, 2016 at 3:12:26 PM UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>> So your answer (extrapolated from below) is that in your graph the nodes >>>> are individual calls not named functions: >>>> >>>> main >>>> / \ >>>> printf print >>>> \ >>>> printf >>>> >>>> In that case it remains a tree even if the call pattern becomes >>>> recursive. >>>> >>> No, because if we disallow recursive calls and function pointers, then we >>> can draw the tree simply by looking through the function source and adding >>> an edge and a child each time a call appears in the source. >>> >> >> The clue is in the name - it is a "call graph", not a "call tree". In a >> "graph", there can be more than one node leading into a given node, not >> just one. >> > > I wrote: > > A structured program consists of a tree of subroutines (functions in C terminology), > which is meant to be roughly balanced - you can't turn a list of commands > into a structured program by drawing lines every so often and converting the > step to a call, and you can't turn a list of commands into a structured program > by saying that each command is actually a subroutine (which it often is in > a lower level sense). it's got to be roughly balanced, non-degenerate tree. > > I did not use the term call graph. And you were wrong to talk about a "tree of subroutines" as though that is a suitable model for describing the structure of code. A "graph of subroutines" is much more useful and accurate. That is why everyone else talks about "call graphs", and only /you/ talk about a tree. Part of this seems to be your confusion between the program structure, which can be described by a call graph (at least, that describes part of the program structure - it does not describe the data structures or data flow), and the control flow of the running program. The control flow of the running program can be described as a tree - if the code is in a procedural programming language with a single thread, structured coding (no "long jumps", for example), no signal handlers, no complicated or delayed callbacks, no recursion unless the depth is known at compile-time, and no co-routines. That is a very limited set of programs - although a good many programs fit those limitations. But it is certainly not the case that only such programs are "structured", nor that a program is structured if it fits those limitations. > Other people said "that's a call graph, and Malcolm has it wrong". > Now someone can use the wrong or a non-standard word for something, > or he can use the right word but describe the entity incorrectly. I have assumed that you know the difference between a "tree" and a "graph". Certainly from your posts it looks like you understand what is meant by "tree", and there at least you are using the standard meaning of the word. > > But he can't do both. If he says "that's a zibra", you may not say "no, you're > wrong, it's a "zebra". And you're wrong again. A zebra has black and white > stripes, that one has pink stripes". >
[toc] | [prev] | [next] | [standalone]
Page 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web