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 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-17 21:57 -0500 |
| Message-ID | <nk2db4$d4s$1@dont-email.me> |
| In reply to | #89410 |
On 6/17/2016 8:18 AM, Malcolm McLean wrote: > On Friday, June 17, 2016 at 2:12:46 PM UTC+1, Martin Shobe wrote: >> >> Structured programming is about the ability to reason about programs. By >> limiting the structures used to those structures that facilitate >> reasoning, you make it easier to write correct programs. That is what >> structured programming is fundamentally about. Limiting blocks to a >> single entry/exit is only a small part of it. >> > No. > Limiting blocks to a single entry / exit point is the heart and soul of it. > There is more. But that's the fundamental idea. Everything else flows > from that. > How? And I don't mean how do you turn the other constructs into blocks with a single entry and exit (Given what you've said about the switch statement, I can do that for any piece of code. I don't even have to change the code.) I want to know how the other precepts follow from single entry/single exit. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 20:54 -0700 |
| Message-ID | <cb471db4-0e94-41ee-b733-86e0bc9da2be@googlegroups.com> |
| In reply to | #89493 |
On Saturday, June 18, 2016 at 3:57:46 AM UTC+1, Martin Shobe wrote: > On 6/17/2016 8:18 AM, Malcolm McLean wrote: > > > No. > > Limiting blocks to a single entry / exit point is the heart and soul of it. > > There is more. But that's the fundamental idea. Everything else flows > > from that. > > > > How? And I don't mean how do you turn the other constructs into blocks > with a single entry and exit (Given what you've said about the switch > statement, I can do that for any piece of code. I don't even have to > change the code.) I want to know how the other precepts follow from > single entry/single exit. > Saying "a block has a single point of entry and exit" is the same as saying "goto statements into and out of the block are disallowed". And that's really the key. A block can be a sequential list of instructions, in which case there is no flow control. Or it can have selection or iteration. In that case, structured programming says that the branch logic is not allowed to "do" anything. All it may do is determine which branch to take, or the number of iterations in the case of a backwards loop. But flow control only has a point if you do something somewhere. So every block which is not a sequential list of atomic instructions must contain at least one sub-block. The crucial point is that a block is a black box. Using the flowchart notation, control starts at the top, it does what it says on the tin, and then it comes out at the bottom. The single entry, single exit criteria are crucial to that. That's the essence of structured programming. The structure is a tree of nested blocks with control statements allowing iteration or selection. A block can also be chopped into two concatenated sub-blocks, when it is carrying out two discrete actions.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-06-17 23:21 -0700 |
| Message-ID | <49630ca8-5de0-4c0f-bb1e-67d8a57fb7c5@googlegroups.com> |
| In reply to | #89498 |
On Friday, June 17, 2016 at 10:54:33 PM UTC-5, Malcolm McLean wrote: > On Saturday, June 18, 2016 at 3:57:46 AM UTC+1, Martin Shobe wrote: > > On 6/17/2016 8:18 AM, Malcolm McLean wrote: > > > > > No. > > > Limiting blocks to a single entry / exit point is the heart and soul of it. > > > There is more. But that's the fundamental idea. Everything else flows > > > from that. > > > > > > > How? And I don't mean how do you turn the other constructs into blocks > > with a single entry and exit (Given what you've said about the switch > > statement, I can do that for any piece of code. I don't even have to > > change the code.) I want to know how the other precepts follow from > > single entry/single exit. > > > Saying "a block has a single point of entry and exit" is the same > as saying "goto statements into and out of the block are disallowed". > And that's really the key. > > A block can be a sequential list of instructions, in which case there > is no flow control. Or it can have selection or iteration. In that > case, structured programming says that the branch logic is not > allowed to "do" anything. All it may do is determine which branch to > take, or the number of iterations in the case of a backwards loop. > But flow control only has a point if you do something somewhere. > So every block which is not a sequential list of atomic instructions > must contain at least one sub-block. > > The crucial point is that a block is a black box. This sentence I agree with. The rest seems like extra "clingy" ideas. It can be a black box with extra arrows. The important part is not the rectilinear perimeter but the blackness inside. Open the box and verify that it does its own little circumspect job. Then close the box and use it as an atom in a larger molecule. Abstraction is what structuring supports. Black boxes can have lots of wires coming out.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 05:18 -0700 |
| Message-ID | <a94a4e71-73d9-4257-9c69-28fd2768aa95@googlegroups.com> |
| In reply to | #89505 |
On Saturday, June 18, 2016 at 7:21:21 AM UTC+1, luser droog wrote: > On Friday, June 17, 2016 at 10:54:33 PM UTC-5, Malcolm McLean wrote: > > On Saturday, June 18, 2016 at 3:57:46 AM UTC+1, Martin Shobe wrote: > > > A block can be a sequential list of instructions, in which case there > > is no flow control. Or it can have selection or iteration. In that > > case, structured programming says that the branch logic is not > > allowed to "do" anything. All it may do is determine which branch to > > take, or the number of iterations in the case of a backwards loop. > > But flow control only has a point if you do something somewhere. > > So every block which is not a sequential list of atomic instructions > > must contain at least one sub-block. > > > > The crucial point is that a block is a black box. > > This sentence I agree with. The rest seems like extra "clingy" ideas. > > It can be a black box with extra arrows. The important part is not > the rectilinear perimeter but the blackness inside. Open the box and > verify that it does its own little circumspect job. Then close the box > and use it as an atom in a larger molecule. > > Abstraction is what structuring supports. Black boxes can have lots of > wires coming out. > Of course they can. There's nothing to stop you from saying that "a block shall have one point of entry and two points of exit, the normal exit and the error exit", or allowing multiple points of entry, or whatever you want. Then you can build your own formal method for software design. The result might be better the Djikstra's work it, might be worse, it might be useful in a few niches. The programs would not be "unstructured messes", they would be "structured programs" in the English sense of the word. But not in the sense that the term is used.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-18 20:19 +0000 |
| Message-ID | <5765ac39.30257296@news.xs4all.nl> |
| In reply to | #89525 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > The result might be better the Djikstra's work it, might be worse, If you can't be bothered to spell Edsger Dijkstra's name correctly, you don't have the right to criticise his work, either. Richard
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-18 12:40 -0500 |
| Message-ID | <nk412i$fm2$1@dont-email.me> |
| In reply to | #89498 |
On 6/17/2016 10:54 PM, Malcolm McLean wrote: > On Saturday, June 18, 2016 at 3:57:46 AM UTC+1, Martin Shobe wrote: >> On 6/17/2016 8:18 AM, Malcolm McLean wrote: >> >>> No. >>> Limiting blocks to a single entry / exit point is the heart and soul of it. >>> There is more. But that's the fundamental idea. Everything else flows >>> from that. >>> >> >> How? And I don't mean how do you turn the other constructs into blocks >> with a single entry and exit (Given what you've said about the switch >> statement, I can do that for any piece of code. I don't even have to >> change the code.) I want to know how the other precepts follow from >> single entry/single exit. >> > Saying "a block has a single point of entry and exit" is the same > as saying "goto statements into and out of the block are disallowed". > And that's really the key. > A block can be a sequential list of instructions, in which case there > is no flow control. Or it can have selection or iteration. In that > case, structured programming says that the branch logic is not > allowed to "do" anything. All it may do is determine which branch to > take, or the number of iterations in the case of a backwards loop. > But flow control only has a point if you do something somewhere. > So every block which is not a sequential list of atomic instructions > must contain at least one sub-block. > > The crucial point is that a block is a black box. Using the flowchart > notation, control starts at the top, it does what it says on the > tin, and then it comes out at the bottom. The single entry, single > exit criteria are crucial to that. The above doesn't show how since it assumes that a block must consist of a sequential list of instructions, selections, and iterations. You are supposed to be showing how a block consists of instructions, selections, and iterations follows from a block having only one entry point and one exit point. > That's the essence of structured programming. The structure is a tree > of nested blocks with control statements allowing iteration or > selection. A block can also be chopped into two concatenated > sub-blocks, when it is carrying out two discrete actions. You also need to show how this tree comes about because a block has only one entry point and one exit point. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 16:37 -0700 |
| Message-ID | <5ee03b84-c17c-49f4-ae5d-5b7bd705d464@googlegroups.com> |
| In reply to | #89540 |
On Saturday, June 18, 2016 at 6:40:40 PM UTC+1, Martin Shobe wrote: > On 6/17/2016 10:54 PM, Malcolm McLean wrote: > > The above doesn't show how since it assumes that a block must consist of > a sequential list of instructions, selections, and iterations. You are > supposed to be showing how a block consists of instructions, selections, > and iterations follows from a block having only one entry point and one > exit point. > A block that consists of a single atomic instruction that "does something" rather than branching. a) has a single point of entry and of exit b) cannot be broken down into two concatenated blocks. c) is leaf. A block that consists of a list of leaf blocks has the same characteristic, and is leaf except for concatenation. A "block" that consists of a concatenation of leaf blocks, but has an additional point of entry or exit, loses the characteristic that it is "leaf" except for concatenation. Whilst we can certainly put curly braces round the definition and declare it to be a "block", what exactly is that supposed to mean? Concatenation seems to follow from the "one entry, one exit" policy. If a block contains a binary branch, then at simplest it consists of the branch, and two leaf blocks, and a join. If a block contains a loop, by definition the loop must go through the same point on each iteration. So a block containing a loop must consist, at the simplest, of a binary branch, a block with one point of entry and of exit, and a path back to block top on one binary branch. Any sequence of blocks (except recursion) can be built up from blocks which are either leaf blocks, simple loops, or binary branches. Any leaf block can be replaced by any block with the same number of entry and exit points. It follows that the entire system is predicated on the number of entry points and exit points being equal for all blocks, and being one. > > > That's the essence of structured programming. The structure is a tree > > of nested blocks with control statements allowing iteration or > > selection. A block can also be chopped into two concatenated > > sub-blocks, when it is carrying out two discrete actions. > > You also need to show how this tree comes about because a block has only > one entry point and one exit point. > Any nesting will produce a tree of sorts. So if you have blocks nested in blocks, you have a tree. Now if a block has only one point of entry and one point of exit, we can define "nesting" quite simply as "any block reachable between the one point of entry and the one point of exit". You can of course devise your own, alternative system of blocks with different characteristics and still say that they nest, still have a tree. But you need a different definition of "nesting". You might even come up with a programming paradigm is better than structured programming, and then you'd be have the right to be annoyed that the term "structured programming" has been taken.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-18 22:08 -0500 |
| Message-ID | <nk52bj$lam$1@dont-email.me> |
| In reply to | #89578 |
On 6/18/2016 6:37 PM, Malcolm McLean wrote: > On Saturday, June 18, 2016 at 6:40:40 PM UTC+1, Martin Shobe wrote: >> On 6/17/2016 10:54 PM, Malcolm McLean wrote: >> >> The above doesn't show how since it assumes that a block must consist of >> a sequential list of instructions, selections, and iterations. You are >> supposed to be showing how a block consists of instructions, selections, >> and iterations follows from a block having only one entry point and one >> exit point. >> > A block that consists of a single atomic instruction that "does something" > rather than branching. > > a) has a single point of entry and of exit > b) cannot be broken down into two concatenated blocks. > c) is leaf. > > A block that consists of a list of leaf blocks has the same > characteristic, and is leaf except for concatenation. > > A "block" that consists of a concatenation of leaf blocks, > but has an additional point of entry or exit, loses the characteristic > that it is "leaf" except for concatenation. Whilst we can certainly > put curly braces round the definition and declare it to be > a "block", what exactly is that supposed to mean? Concatenation seems > to follow from the "one entry, one exit" policy. > > If a block contains a binary branch, then at simplest it consists > of the branch, and two leaf blocks, and a join. > > If a block contains a loop, by definition the loop must go through the > same point on each iteration. So a block containing a loop must > consist, at the simplest, of a binary branch, a block with one > point of entry and of exit, and a path back to block top on > one binary branch. > > Any sequence of blocks (except recursion) can be built up from > blocks which are either leaf blocks, simple loops, or binary branches. > Any leaf block can be replaced by any block with the same number > of entry and exit points. > > It follows that the entire system is predicated on the number of > entry points and exit points being equal for all blocks, and being > one. You're showing how you can preserve the single entry/exit property with these items. You're supposed to be showing how a block consists of instructions, selections, and iterations follows from a block having only one entry point and one exit point. >>> That's the essence of structured programming. The structure is a tree >>> of nested blocks with control statements allowing iteration or >>> selection. A block can also be chopped into two concatenated >>> sub-blocks, when it is carrying out two discrete actions. >> >> You also need to show how this tree comes about because a block has only >> one entry point and one exit point. >> > Any nesting will produce a tree of sorts. > So if you have blocks nested in blocks, you have a tree. And if you don't have blocks nested in blocks? > Now if a block has only one point of entry and one point of exit, > we can define "nesting" quite simply as "any block reachable > between the one point of entry and the one point of exit". That would be a very odd definition of "nesting". > You can of course devise your own, alternative system of blocks > with different characteristics and still say that they nest, still > have a tree. But you need a different definition of "nesting". And now you're really off-track. You're supposed to be showing how this tree comes about from single entry/exit not fantasizing about other systems. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 21:02 -0700 |
| Message-ID | <f89d43db-b510-477f-b11e-652b55dc1fa1@googlegroups.com> |
| In reply to | #89599 |
On Sunday, June 19, 2016 at 4:08:45 AM UTC+1, Martin Shobe wrote: > On 6/18/2016 6:37 PM, Malcolm McLean wrote: > > You're showing how you can preserve the single entry/exit property with > these items. You're supposed to be showing how a block consists of > instructions, selections, and iterations follows from a block having > only one entry point and one exit point. > It doesn't. It's the "heart and soul" of the idea. Blocks don't have to be structured internally, but if you follow the rules, they must either be atomic leaves or consist of other blocks and diamonds (binary branches). > > > Any nesting will produce a tree of sorts. > > So if you have blocks nested in blocks, you have a tree. > > And if you don't have blocks nested in blocks? > You don't have a tree, and so you don't have a structured program. > > > Now if a block has only one point of entry and one point of exit, > > we can define "nesting" quite simply as "any block reachable > > between the one point of entry and the one point of exit". > > That would be a very odd definition of "nesting". > Seems perfectly natural to me. > > > You can of course devise your own, alternative system of blocks > > with different characteristics and still say that they nest, still > > have a tree. But you need a different definition of "nesting". > > And now you're really off-track. You're supposed to be showing how this > tree comes about from single entry/exit not fantasizing about other > systems. > An atomic instruction which is not a branch has one point of entry and of exit, and is leaf. A concatenation of such instructions can replace or be replaced by any atomic instruction which has equivalent effect, if and only if it has only one point of entry and one point of exit. So that's essentially how you get nesting. It's inherent in the rule. If you say, "let's change the rule" you don't prevent nesting, but you abolish that type of nesting and you must define it differently.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-19 00:17 -0500 |
| Message-ID | <nk59tt$64n$1@dont-email.me> |
| In reply to | #89601 |
On 6/18/2016 11:02 PM, Malcolm McLean wrote: > On Sunday, June 19, 2016 at 4:08:45 AM UTC+1, Martin Shobe wrote: >> On 6/18/2016 6:37 PM, Malcolm McLean wrote: >> >> You're showing how you can preserve the single entry/exit property with >> these items. You're supposed to be showing how a block consists of >> instructions, selections, and iterations follows from a block having >> only one entry point and one exit point. >> > It doesn't. Is that a retraction of your claim that it does? > It's the "heart and soul" of the idea. No, the "heart and soul" of the idea is the ability to reason about programs. > Blocks don't have to be structured internally, but if you follow the > rules, they must either be atomic leaves or consist of other > blocks and diamonds (binary branches). And this violates the "heart and soul" of the idea. In what others call structured programming, it does have to be structured internally (at least for the code being written). >>> Any nesting will produce a tree of sorts. >>> So if you have blocks nested in blocks, you have a tree. >> >> And if you don't have blocks nested in blocks? > You don't have a tree, and so you don't have a structured > program. So if blocks with single entry/exit aren't nested, you don't have the tree. It thereby follows that the tree doesn't follow from single entry/exit. Will you retract that claim as well? That makes you 0-2 in supporting your claim that the other properties follow from single entry/exit. >>> Now if a block has only one point of entry and one point of exit, >>> we can define "nesting" quite simply as "any block reachable >>> between the one point of entry and the one point of exit". >> >> That would be a very odd definition of "nesting". >> > Seems perfectly natural to me. Nesting requires that one is, in some sense, inside the other. Blocks that are reachable would include such blocks, but would also include blocks that aren't inside, e.g. calling an external function. >>> You can of course devise your own, alternative system of blocks >>> with different characteristics and still say that they nest, still >>> have a tree. But you need a different definition of "nesting". >> >> And now you're really off-track. You're supposed to be showing how this >> tree comes about from single entry/exit not fantasizing about other >> systems. >> > An atomic instruction which is not a branch has one point of entry > and of exit, and is leaf. A concatenation of such instructions > can replace or be replaced by any atomic instruction which has > equivalent effect, if and only if it has only one point of > entry and one point of exit. > So that's essentially how you get nesting. It's inherent in the > rule. > If you say, "let's change the rule" you don't prevent nesting, > but you abolish that type of nesting and you must define it > differently. That would obviously depend on what you changed it too. However, it's all irrelevant to showing how the tree follows from single entry/exit. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 22:33 -0700 |
| Message-ID | <db51e697-35cc-4ea8-b4d5-4da5b199c8e5@googlegroups.com> |
| In reply to | #89603 |
On Sunday, June 19, 2016 at 6:17:58 AM UTC+1, Martin Shobe wrote: > > Nesting requires that one is, in some sense, inside the other. Blocks > that are reachable would include such blocks, but would also include > blocks that aren't inside, e.g. calling an external function. > So inline the external function. Now it's nested. > > That would obviously depend on what you changed it too. However, it's > all irrelevant to showing how the tree follows from single entry/exit. > It seems you're not going to get it. If we have a single point of entry and a single point of exit, we create an interval or space or step or "block" to whatever you want to think of it as. So anything that happens between the point of entry and the point of exit is "inside", everything that doesn't is "outside". But since you have only one point of entry and one point of exit, there can't be a second interval in which an event is inside that "overlaps". We have an event that is inside block A, and also inside block B, so either block A is inside block B, or block B is inside block A. So there must be nesting. It's enforced by the single entry single exit requirement.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-19 12:07 -0500 |
| Message-ID | <nk6jhl$61i$1@dont-email.me> |
| In reply to | #89604 |
On 6/19/2016 12:33 AM, Malcolm McLean wrote: > On Sunday, June 19, 2016 at 6:17:58 AM UTC+1, Martin Shobe wrote: >> >> Nesting requires that one is, in some sense, inside the other. Blocks >> that are reachable would include such blocks, but would also include >> blocks that aren't inside, e.g. calling an external function. >> > So inline the external function. > Now it's nested. The fact that some other code is nested doesn't make the current code nested. >> That would obviously depend on what you changed it too. However, it's >> all irrelevant to showing how the tree follows from single entry/exit. > It seems you're not going to get it. It also seems you aren't going to supply any evidence to support your claim. The below certainly doesn't qualify. > If we have a single point of entry and a single point of exit, > we create an interval or space or step or "block" to whatever > you want to think of it as. > So anything that happens between the point of entry and the > point of exit is "inside", everything that doesn't is "outside". > But since you have only one point of entry and one point of exit, > there can't be a second interval in which an event is inside > that "overlaps". We have an event that is inside block A, and > also inside block B, so either block A is inside block B, > or block B is inside block A. > So there must be nesting. It's enforced by the single entry > single exit requirement. Of course this forms a tree. However, it's not the tree you want since this tree is also formed when recursion is used. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 10:38 -0700 |
| Message-ID | <385a5ef4-e078-4fe1-8bf3-ed39ffcf4ec2@googlegroups.com> |
| In reply to | #89619 |
On Sunday, June 19, 2016 at 6:08:13 PM UTC+1, Martin Shobe wrote: > On 6/19/2016 12:33 AM, Malcolm McLean wrote: > > On Sunday, June 19, 2016 at 6:17:58 AM UTC+1, Martin Shobe wrote: > >> > >> Nesting requires that one is, in some sense, inside the other. Blocks > >> that are reachable would include such blocks, but would also include > >> blocks that aren't inside, e.g. calling an external function. > >> > > So inline the external function. > > Now it's nested. > > The fact that some other code is nested doesn't make the current code > nested. > > >> That would obviously depend on what you changed it too. However, it's > >> all irrelevant to showing how the tree follows from single entry/exit. > > > It seems you're not going to get it. > > It also seems you aren't going to supply any evidence to support your > claim. The below certainly doesn't qualify. > > > If we have a single point of entry and a single point of exit, > > we create an interval or space or step or "block" to whatever > > you want to think of it as. > > So anything that happens between the point of entry and the > > point of exit is "inside", everything that doesn't is "outside". > > But since you have only one point of entry and one point of exit, > > there can't be a second interval in which an event is inside > > that "overlaps". We have an event that is inside block A, and > > also inside block B, so either block A is inside block B, > > or block B is inside block A. > > So there must be nesting. It's enforced by the single entry > > single exit requirement. > > Of course this forms a tree. However, it's not the tree you want since > this tree is also formed when recursion is used. > Try drawing the trees for a recursive and non-recursive structured program using the rules outlined (each function has one point of entry and one point of exit). That should reveal the issue.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-19 21:07 +0100 |
| Message-ID | <878ty1q6xd.fsf@bsb.me.uk> |
| In reply to | #89620 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Try drawing the trees for a recursive and non-recursive structured
> program using the rules outlined (each function has one point
> of entry and one point of exit).
> That should reveal the issue.
I'm going to start by trying to draw the Malcolm-call-tree for a
non-recursive program so let's remind ourselves of the construction you
gave. In order not to have a graph you insist that:
"The nodes are calls, not function definitions."
but these are not dynamic calls during the execution of the code but
simply calls that appear in the text:
"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"
So given
void a(void) { b(); d(); }
void b(void) { d(); }
void d(void) { }
you don't draw the usual call graph
a
/ \
b-->d
you draw, instead
a
/ \
b d
/
d
(all with down pointing arrows of course). There are two calls to d in
the text so the construction will give two nodes called d. But what
about
void a(void) { b(); d(); }
void b(void) { d(); }
void d(void) { e(); }
void e(void) { }
Your construction just adds a child (one child) and an edge (one edge)
for every call in the source and I've just added one call to e into the
source, so what tree do I draw?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-19 13:36 -0700 |
| Message-ID | <53123faf-e7c4-4096-b4d9-5dbdcf94569b@googlegroups.com> |
| In reply to | #89623 |
On Sunday, June 19, 2016 at 3:07:20 PM UTC-5, Ben Bacarisse wrote:
> So given
>
> void a(void) { b(); d(); }
> void b(void) { d(); }
> void d(void) { }
>
> you don't draw the usual call graph
>
> a
> / \
> b-->d
>
> you draw, instead
>
> a
> / \
> b d
> /
> d
>
> (all with down pointing arrows of course). There are two calls to d in
> the text so the construction will give two nodes called d. But what
> about
>
> void a(void) { b(); d(); }
> void b(void) { d(); }
> void d(void) { e(); }
> void e(void) { }
>
> Your construction just adds a child (one child) and an edge (one edge)
> for every call in the source and I've just added one call to e into the
> source, so what tree do I draw?
When inspecting the source of the left side d, you add a node e from that,
and you do likewise for the source of the right side d (ignoring the fact
that it's the same source file).
If a program does not make any recursive function calls nor any potentially-
recursive calls via function pointers, it would be possible to draw a finite
(albeit in many cases large) tree which could--if the tree included back-
links--allow the program to be processed without any stack whatsoever.
While that would entail an excessive level of code duplication, there are
times such an approach may be worthwhile, at least for simple programs.
Having a program use "return" instructions at all, for example, makes it
very hard to guard against certain kinds of electrical-glitch events,
compared with having a program that inline-expands everything. I've not
seen a C compiler with options for the latter, though I've written some
assembly language programs under such constraints. A compiler for a limited
subset of C which could handle such constraints might have been helpful if
one existed.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 13:50 -0700 |
| Message-ID | <c8ff017c-6958-464c-a632-4138c35fe52b@googlegroups.com> |
| In reply to | #89623 |
On Sunday, June 19, 2016 at 9:07:20 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> So given
>
> void a(void) { b(); d(); }
> void b(void) { d(); }
> void d(void) { }
>
> you don't draw the usual call graph
>
> a
> / \
> b-->d
>
> you draw, instead
>
> a
> / \
> b d
> /
> d
>
> (all with down pointing arrows of course). There are two calls to d in
> the text so the construction will give two nodes called d. But what
> about
>
> void a(void) { b(); d(); }
> void b(void) { d(); }
> void d(void) { e(); }
> void e(void) { }
>
> Your construction just adds a child (one child) and an edge (one edge)
> for every call in the source and I've just added one call to e into the
> source, so what tree do I draw?
>
a
/ \
b d
/ \e
d
/
e
d nodes are identical, but not duplicates.
(for most purposes, the call graph is fine, but not for example if
d take a constant parameter in one call and a variable in another,
and we wish to discuss how to optimise the program).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-19 22:42 +0100 |
| Message-ID | <8737o8rh2n.fsf@bsb.me.uk> |
| In reply to | #89625 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, June 19, 2016 at 9:07:20 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> So given
>>
>> void a(void) { b(); d(); }
>> void b(void) { d(); }
>> void d(void) { }
>>
>> you don't draw the usual call graph
>>
>> a
>> / \
>> b-->d
>>
>> you draw, instead
>>
>> a
>> / \
>> b d
>> /
>> d
>>
>> (all with down pointing arrows of course). There are two calls to d in
>> the text so the construction will give two nodes called d. But what
>> about
>>
>> void a(void) { b(); d(); }
>> void b(void) { d(); }
>> void d(void) { e(); }
>> void e(void) { }
>>
>> Your construction just adds a child (one child) and an edge (one edge)
>> for every call in the source and I've just added one call to e into the
>> source, so what tree do I draw?
>>
> a
> / \
> b d
> / \e
> d
> /
> e
>
> d nodes are identical, but not duplicates.
That's odd. They appear to represent different calls in the source. I
would not call that identical (one is "call d on line 1" the other is
"call of d on line 2") but the construction is yours after all. If
being identical still allows them to be separate, so be it.
> (for most purposes, the call graph is fine, but not for example if
> d take a constant parameter in one call and a variable in another,
> and we wish to discuss how to optimise the program).
Can you write the rule in a way that will let someone draw the
Malcolm-call-tree for themselves? This (which for some reason you cut)
"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"
does not cover that situation. It suggests a one-to-one correspondence
between calls appearing in the source and nodes in the tree.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-19 23:16 +0100 |
| Message-ID | <nk75jo$8dv$1@dont-email.me> |
| In reply to | #89627 |
On 19/06/2016 22:42, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Sunday, June 19, 2016 at 9:07:20 PM UTC+1, Ben Bacarisse wrote:
>>> void a(void) { b(); d(); }
>>> void b(void) { d(); }
>>> void d(void) { e(); }
>>> void e(void) { }
>>>
>>> Your construction just adds a child (one child) and an edge (one edge)
>>> for every call in the source and I've just added one call to e into the
>>> source, so what tree do I draw?
>>>
>> a
>> / \
>> b d
>> / \e
>> d
>> /
>> e
>>
>> d nodes are identical, but not duplicates.
>
> That's odd.
I've little idea what you two are arguing about. But if the dynamic
calls in your example are displayed, then I get a graph pretty much like
Malcolm's (rotated and flipped and offset, but the same, although
Malcolm has a misplaced 'e' in his.)
What's more odd is what's happened to c().
#include <stdio.h>
int level=0;
void b(void);
void d(void);
void e(void);
void display(char* s) {
printf("%.*s%s\n",level*2,
" ",s);
}
void a(void) {
++level;
display("A");
b(); d();
--level;
}
void b(void) {
++level;
display("B");
d();
--level;
}
void d(void) {
++level;
display("D");
e();
--level;
}
void e(void) {
++level;
display("E");
--level;
}
int main(void){
a();
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 00:12 +0100 |
| Message-ID | <87wplkpyco.fsf@bsb.me.uk> |
| In reply to | #89628 |
BartC <bc@freeuk.com> writes:
<snip>
> I've little idea what you two are arguing about. But if the dynamic
> calls in your example are displayed, then I get a graph pretty much
> like Malcolm's
The Malcolm-call-tree is not the dynamic tree of calls because that does
not have the property he wants for recursive programs (it remains a
tree), and it's not the usual static call graph because that's not
always a tree. It's something in between.
<snip>
> void display(char* s) {
> printf("%.*s%s\n",level*2,
> " ",s);
> }
I use
printf("%*s", level * 2, "");
for things like this.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-19 16:35 -0700 |
| Message-ID | <18a8b9f5-7c4a-48cf-b052-ac81100e4396@googlegroups.com> |
| In reply to | #89632 |
On Monday, June 20, 2016 at 12:12:31 AM UTC+1, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> > > I've little idea what you two are arguing about. But if the dynamic > > calls in your example are displayed, then I get a graph pretty much > > like Malcolm's > > The Malcolm-call-tree is not the dynamic tree of calls because that does > not have the property he wants for recursive programs (it remains a > tree), and it's not the usual static call graph because that's not > always a tree. It's something in between. > Exactly. The Malcolm-call-tree, (I can't see that name sticking, but it's a chance for fame) is the structure of a structured program, with blocks that are not subroutines replaced by spaghetti code. (They won't really be spaghetti code, at least not normally, but they don't appear in the tree). That's how modern structured programming has developed. Subroutines are blocks (single point of entry and of exit), and are heavily used to break the program down into manageable chunks. They are not primarily used so that they can be called from two separate points, though that is an additional property. And the subroutines are not themselves written as strict structured programs, they are nearly structured but not quite.
[toc] | [prev] | [next] | [standalone]
Page 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web