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 8 of 19 — ← Prev page 1 … 6 7 [8] 9 10 … 19 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 16:44 +0100 |
| Message-ID | <87poramtrq.fsf@bsb.me.uk> |
| In reply to | #89694 |
David Brown <david.brown@hesbynett.no> writes: <snip> > Trees are great for climbing - but useless as models of call behaviour > and structure in programs. That's a very odd remark! It may be that the context makes it reasonable but I could see how (so, forgive me, I cut the context). The stack of function call activations can be modelled as a linked list but if instead of unlinking on pop you leave the node in place and when you push a call you make a sibling to all existing calls the result is a tree. It's the trace of all the pushing a popping over time. For ordinary function calls, a tree is the natural model of the dynamic call structure. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-21 19:50 +0200 |
| Message-ID | <nkbuon$1hs$1@dont-email.me> |
| In reply to | #89710 |
On 21/06/16 17:44, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> >> Trees are great for climbing - but useless as models of call behaviour >> and structure in programs. > > That's a very odd remark! It may be that the context makes it > reasonable but I could see how (so, forgive me, I cut the context). > > The stack of function call activations can be modelled as a linked list > but if instead of unlinking on pop you leave the node in place and when > you push a call you make a sibling to all existing calls the result is a > tree. It's the trace of all the pushing a popping over time. For > ordinary function calls, a tree is the natural model of the dynamic call > structure. > Yes, of course trees are a fine model for the dynamic call behaviour when code is running (unless you have a language supporting coroutines). It is for the static structure that you need a graph rather than a tree. (I'm off on holiday for a bit, so I am unlikely to reply for a while.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 16:33 +0100 |
| Message-ID | <87vb12mu99.fsf@bsb.me.uk> |
| In reply to | #89682 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > What's the point in structured programming? > The so-called Malcolm call-tree is the structure of a structured > program. A tree, with cycles for recursion. > The entire paradigm is designed to force the program into this > pattern. No it isn't. Nothing I've read the almost 40 years I've been reading about structured programming uses your specific tree (the one you've made up to exclude recursion and calls to function though data values) to define what makes a program strucured. In fact, both are common techniques in structured programming. You've produced no references to support the idea that this specific tree is used to define the structure of structured programs, and there is ample evidence to the contrary. What's more, even your basic tenet is denied in the classic "Structured Programming" text. When discussing the advantages offered by SIMLUA the author highlights the fact that block activations (roughly the result of your inlining process that makes a tree) are no longer nested. Whilst the procedure calls and returns are nested, you can no longer model the data as nested blocks and your inlining process would fail. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-21 10:54 -0700 |
| Message-ID | <lnporaqvf3.fsf@kst-u.example.com> |
| In reply to | #89709 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> What's more, even your basic tenet is denied in the classic "Structured
> Programming" text. When discussing the advantages offered by SIMLUA the
> author highlights the fact that block activations (roughly the result of
> your inlining process that makes a tree) are no longer nested. Whilst
> the procedure calls and returns are nested, you can no longer model the
> data as nested blocks and your inlining process would fail.
Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a
hybrid of SIMULA and Lua, might be an intereseting language, though.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-21 20:02 +0100 |
| Message-ID | <87k2himklg.fsf@bsb.me.uk> |
| In reply to | #89715 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> What's more, even your basic tenet is denied in the classic "Structured >> Programming" text. When discussing the advantages offered by SIMLUA the >> author highlights the fact that block activations (roughly the result of >> your inlining process that makes a tree) are no longer nested. Whilst >> the procedure calls and returns are nested, you can no longer model the >> data as nested blocks and your inlining process would fail. > > Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a > hybrid of SIMULA and Lua, might be an intereseting language, though.) Thanks. (It's getting worse -- it took nearly a minute for me to see the difference between the two even when side by side like that.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-21 21:13 +0100 |
| Message-ID | <nkc75s$32i$1@dont-email.me> |
| In reply to | #89720 |
On 21/06/2016 20:02, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> [...] >>> What's more, even your basic tenet is denied in the classic "Structured >>> Programming" text. When discussing the advantages offered by SIMLUA the >>> author highlights the fact that block activations (roughly the result of >>> your inlining process that makes a tree) are no longer nested. Whilst >>> the procedure calls and returns are nested, you can no longer model the >>> data as nested blocks and your inlining process would fail. >> >> Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a >> hybrid of SIMULA and Lua, might be an intereseting language, though.) > > Thanks. (It's getting worse -- it took nearly a minute for me to see > the difference between the two even when side by side like that.) > (Me too...) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-21 13:45 -0700 |
| Message-ID | <lneg7qqnjb.fsf@kst-u.example.com> |
| In reply to | #89734 |
BartC <bc@freeuk.com> writes:
> On 21/06/2016 20:02, Ben Bacarisse wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> [...]
>>>> What's more, even your basic tenet is denied in the classic "Structured
>>>> Programming" text. When discussing the advantages offered by SIMLUA the
>>>> author highlights the fact that block activations (roughly the result of
>>>> your inlining process that makes a tree) are no longer nested. Whilst
>>>> the procedure calls and returns are nested, you can no longer model the
>>>> data as nested blocks and your inlining process would fail.
>>>
>>> Just for the sake of anyone doing web searches, it's SIMULA. (SIMLUA, a
>>> hybrid of SIMULA and Lua, might be an intereseting language, though.)
>>
>> Thanks. (It's getting worse -- it took nearly a minute for me to see
>> the difference between the two even when side by side like that.)
>>
>
> (Me too...)
And I meant "interesting", not "intereseting". Naturally, it took two
followups before I noticed that typo.
Muphry's Law (sic) strikes again.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-06-20 10:00 -0700 |
| Message-ID | <9510258e-e09e-41ba-aa7d-65ecd9c5906d@googlegroups.com> |
| In reply to | #89644 |
On Monday, June 20, 2016 at 5:12:58 AM UTC-5, Malcolm McLean wrote: > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: > > On 20/06/16 10:22, Malcolm McLean wrote: > > > > But it doesn't. No, Malcolm, it really doesn't. A recursive function is > > just a function. Getting the hang of them is a bit weird at first, but > > once you've got past that stage (which should happen quite early on in > > one's programming experience) they are an extraordinarily useful tool > > and one that makes many programs much simpler to encode with a sensible, > > manageable structure. Can they be abused? Hell yes. So can anything. > > But, used sensibly, they are a blessing and a boon. > > > A recursive function is not just another subroutine call. > It has properties which are fundamentally different. > > > > I wonder what MumbleCo would have made of that... being forced to > > simulate loops with recursion AND simulate recursion with loops! :-) > > > You can ban either loops or recursion, but not both. This is true, but we're on the wrong borderline. According to the Bohm-Jacopini theorem, https://en.wikipedia.org/wiki/Structured_program_theorem you need sequencing, selection (if), and iteration (either recursion or loops). If you remove one of those pieces you lose the power of the Turing Machine. Can't program anything anymore, structured or otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 22:07 +0100 |
| Message-ID | <874m8no9gt.fsf@bsb.me.uk> |
| In reply to | #89644 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: >> On 20/06/16 10:22, Malcolm McLean wrote: >> >> But it doesn't. No, Malcolm, it really doesn't. A recursive function is >> just a function. Getting the hang of them is a bit weird at first, but >> once you've got past that stage (which should happen quite early on in >> one's programming experience) they are an extraordinarily useful tool >> and one that makes many programs much simpler to encode with a sensible, >> manageable structure. Can they be abused? Hell yes. So can anything. >> But, used sensibly, they are a blessing and a boon. >> > A recursive function is not just another subroutine call. > It has properties which are fundamentally different. That's true but largely beside the point because the point you are making is not about recursive *function* but recursive *programs*. You can't always tell, just be by looking at it, if a function is going to be involved in a recursive call (f calls g calls h call f) and that's a problem because some programming languages allow functions to be written so that they are not re-entrant. The classic example being 'own' variables in Algol 60. This is a telling point. If you read the classic "Structured Programming" book (citation from me elsewhere in this thread) you will see this problem mentioned by Dijksata. But he does not blame recursion for being unstructured but 'own' declarations for interfering with the structure of recursion. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 19:08 -0700 |
| Message-ID | <fac4ad0c-d099-487f-8ee5-d369a872f915@googlegroups.com> |
| In reply to | #89672 |
On Monday, June 20, 2016 at 10:07:37 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, June 20, 2016 at 10:51:15 AM UTC+1, Richard Heathfield wrote: > >> On 20/06/16 10:22, Malcolm McLean wrote: > >> > >> But it doesn't. No, Malcolm, it really doesn't. A recursive function is > >> just a function. Getting the hang of them is a bit weird at first, but > >> once you've got past that stage (which should happen quite early on in > >> one's programming experience) they are an extraordinarily useful tool > >> and one that makes many programs much simpler to encode with a sensible, > >> manageable structure. Can they be abused? Hell yes. So can anything. > >> But, used sensibly, they are a blessing and a boon. > >> > > A recursive function is not just another subroutine call. > > It has properties which are fundamentally different. > > That's true but largely beside the point because the point you are > making is not about recursive *function* but recursive *programs*. You > can't always tell, just be by looking at it, if a function is going to > be involved in a recursive call (f calls g calls h call f) and that's a > problem because some programming languages allow functions to be written > so that they are not re-entrant. The classic example being 'own' > variables in Algol 60. > > This is a telling point. If you read the classic "Structured > Programming" book (citation from me elsewhere in this thread) you will > see this problem mentioned by Dijksata. But he does not blame recursion > for being unstructured but 'own' declarations for interfering with the > structure of recursion. > Nothing I am saying is new. I didn't invent structured programming.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-22 01:15 +0100 |
| Message-ID | <87oa6ukrih.fsf@bsb.me.uk> |
| In reply to | #89683 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 10:07:37 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> >> > A recursive function is not just another subroutine call. >> > It has properties which are fundamentally different. >> >> That's true but largely beside the point because the point you are >> making is not about recursive *function* but recursive *programs*. You >> can't always tell, just be by looking at it, if a function is going to >> be involved in a recursive call (f calls g calls h call f) and that's a >> problem because some programming languages allow functions to be written >> so that they are not re-entrant. The classic example being 'own' >> variables in Algol 60. >> >> This is a telling point. If you read the classic "Structured >> Programming" book (citation from me elsewhere in this thread) you will >> see this problem mentioned by Dijksata. But he does not blame recursion >> for being unstructured but 'own' declarations for interfering with the >> structure of recursion. >> > Nothing I am saying is new. Yet you can't cite anyone who's said these things before: that recursion is antithetical to structured programming; that using function pointers (as data) are also; and that a call graph with a special rule for recursion and no rule at all for unnamed functions is used to justify the first two. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-20 12:38 +0000 |
| Message-ID | <5767e37f.9813515@news.xs4all.nl> |
| In reply to | #89642 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, June 20, 2016 at 10:11:12 AM UTC+1, Richard Heathfield wrote: > > Why does a program have to be balanced in order to be structured? > > > A degnerate tree loses most of the desirable characteristics of a > balanced tree. You know, there is a whole forest of trees between the extremes of "balanced" and "degenerate". In the case of program structure, neither extreme is ideal. You're not implementing a binary search over code lines, after all. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-20 15:48 +0100 |
| Message-ID | <87eg7rq5kv.fsf@bsb.me.uk> |
| In reply to | #89636 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, June 20, 2016 at 1:24:31 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > Simply take some C source without gotos, breaks, continues or >> > switches, and indent it in the conventional way. >> > Now inline all the function calls manually. Forget static variables >> > for the moment and function pointers and recursion. >> > >> > Now you have "the tree". >> >> No I don't. I get a tree if I follow a set of rules that constructs it. >> For example, my best guess for your rule is that as you inline a >> function you create a new node and add an edge from the node >> representing the (inlined) calling function to the new node. >> >> But this rule will give you tree even for a recursive program so let me >> know if this is not how your tree is constructed. You have not yet provided the rules to build the tree from whatever process you want to employ. I tried to guess the construction from what you have said, but the resulting tree would have no cycles. Can you give the rules please? Are they really complicated? I want it to 100% clear that recursion is treated as a special case by your construction. Please don't just repeat a process the produces an expanded program text. Your claim was about trees and, specifically, cycles in them so I need the rules about how the tree is built as the program text is gradually expanded step by step. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-20 23:17 -0500 |
| Message-ID | <nkaf4q$6e0$1@dont-email.me> |
| In reply to | #89620 |
On 6/19/2016 12:38 PM, Malcolm McLean wrote: > 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. > You get a tree either way. Is that the issue? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-20 21:43 -0700 |
| Message-ID | <bae6dc9d-3808-4af6-9863-db1411d1bbe4@googlegroups.com> |
| In reply to | #89688 |
On Tuesday, June 21, 2016 at 5:17:39 AM UTC+1, Martin Shobe wrote: > > > 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. > > > > You get a tree either way. Is that the issue? > It depends exactly how you draw it. The tree is the tree of block nesting. Each block has one point of entry and of exit. So if it contains another block, there must be strict nesting. Blocks cannot overlap. But can it contain itself? What rules do you need to preserve the "one point of entry and of exit" property, and the tree property?
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-21 06:36 -0500 |
| Message-ID | <nkb8ra$gkg$1@dont-email.me> |
| In reply to | #89690 |
On 6/20/2016 11:43 PM, Malcolm McLean wrote: > On Tuesday, June 21, 2016 at 5:17:39 AM UTC+1, Martin Shobe wrote: >> >>> 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. >>> >> >> You get a tree either way. Is that the issue? >> > It depends exactly how you draw it. > > The tree is the tree of block nesting. If it's a tree of block nesting, you get a tree with or without recursion. In fact, you get a tree here as long as blocks don't partially overlap, even if those blocks have more than one entry/exit. > Each block has one point > of entry and of exit. So if it contains another block, there must > be strict nesting. Blocks cannot overlap. > But can it contain itself? No. > What rules do you need to preserve the "one point of entry and > of exit" property, and the tree property? The simplest would probably be, "Blocks shall only have one point of entry and of exit." and "Blocks shall not partially overlap." Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-06-18 10:35 -0400 |
| Message-ID | <3%c9z.1223$LY5.217@fx21.iad> |
| In reply to | #89493 |
On 6/17/16 10:57 PM, Martin Shobe wrote:
> 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
>
My understanding of what was meant by 'Structured Programming' was a
program could be looked at as a set of 'Blocks' (The top most block
being the entire program itself), these blocks having a single entry and
exit, and each block being built of one of a limited number of
acceptable structural forms:
* the simplest form was a block could have a linear sequence of other blocks
* it could also have a conditional sequence where a block was executed
or not based on a condition
* there were also looping constructs where a block would execute until a
condition was true (there were two variations with the test in front or
after the executed block)
* there was a n-way switch where one of n block would be executed and
then the path of execution rejoined
* there was a subroutine call (this sort of breaks the single
entry/single exit rule, but in a very controlled manner)
* and the corresponding subroutine definition.
(I think that is the complete list)
There is a bit of redundancy in the list as n-way and conditional can be
used to implement each other and there are ways to transform between
leading and trailing tested loops into each other (with some added
complexity).
Any program that was to be considered 'Structured' could be broken down
into these blocks, and failure to be able to do so was the proof that
you program wasn't structured.
This didn't totally prohibit the use of goto statements, just that gotos
could only be used to build these structured elements. In some
languages, like FORTRAN, you needed to use a goto as the if statement
didn't take blocks. In C, you could generally avoid gotos, but in a few
cases you could sometimes argue that they were implementing structure.
An example would be something like:
if(!a) {
...
if(!b) {
...
if(!c) {
...
}
...
}
...
}
could be transformed to reduce indent level to:
if(a) goto end1;
...
if(b) goto end2;
...
if(c) goto end3;
...
end3:
...
end2:
...
end1:
Purist would argue against this, pointing out that you could no longer
verify that the code was structured by a 'simple' inspection (you needed
to make sure that the gotos did land in accordance to the rules of
structure, and if your going to have to do that, you might as well have
just used an unstructured language like FORTRAN. Pragmatist would argue
that all the levels of indentation made the code too hard to read.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-06-18 12:48 -0500 |
| Message-ID | <nk41i2$hdq$1@dont-email.me> |
| In reply to | #89533 |
On 6/18/2016 9:35 AM, Richard Damon wrote: > On 6/17/16 10:57 PM, Martin Shobe wrote: >> 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 >> > > My understanding of what was meant by 'Structured Programming' was a > program could be looked at as a set of 'Blocks' (The top most block > being the entire program itself), these blocks having a single entry and > exit, and each block being built of one of a limited number of > acceptable structural forms: > > * the simplest form was a block could have a linear sequence of other > blocks > * it could also have a conditional sequence where a block was executed > or not based on a condition > * there were also looping constructs where a block would execute until a > condition was true (there were two variations with the test in front or > after the executed block) > * there was a n-way switch where one of n block would be executed and > then the path of execution rejoined > * there was a subroutine call (this sort of breaks the single > entry/single exit rule, but in a very controlled manner) You're only violating it if you don't return in the normal manner. > * and the corresponding subroutine definition. > (I think that is the complete list) > > There is a bit of redundancy in the list as n-way and conditional can be > used to implement each other and there are ways to transform between > leading and trailing tested loops into each other (with some added > complexity). > > Any program that was to be considered 'Structured' could be broken down > into these blocks, and failure to be able to do so was the proof that > you program wasn't structured. > > This didn't totally prohibit the use of goto statements, just that gotos > could only be used to build these structured elements. In some > languages, like FORTRAN, you needed to use a goto as the if statement > didn't take blocks. In C, you could generally avoid gotos, but in a few > cases you could sometimes argue that they were implementing structure. > Aside from the one comment above, I agree with this. This is also what I understand structured programming to be. Malcolm has claimed that the restrictions to the allowed structures follows from a single entry/exit. I don't see how, do you? [example snipped] Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-06-18 23:11 -0400 |
| Message-ID | <F3o9z.3345$HD2.2283@fx37.iad> |
| In reply to | #89541 |
On 6/18/16 1:48 PM, Martin Shobe wrote: > On 6/18/2016 9:35 AM, Richard Damon wrote: >> * there was a subroutine call (this sort of breaks the single >> entry/single exit rule, but in a very controlled manner) > > You're only violating it if you don't return in the normal manner. > The issue is some people look at the call block and see two entrances and two exits. The entrance from to code before, and the entrance from the return, and two exits, the exit to the following code, and an exit to the called subroutine. They also see the subroutine as having many entrances, one for each call point and an exit back towards each of the call points. This is mostly done by people who dislike the 'restraints' that structure programming applies, and want to claim it doesn't really help. In one sense, at the very detailed machine code, the claim has some accuracy. The key factor is that at the level of the programmers thinking about it, a subroutine call is a light cognitive load, similar to the other structured blocks.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-18 21:06 -0700 |
| Message-ID | <e2dbdd21-c4fb-4c33-9581-87518ab23622@googlegroups.com> |
| In reply to | #89600 |
On Sunday, June 19, 2016 at 4:11:41 AM UTC+1, Richard Damon wrote: > > The issue is some people look at the call block and see two entrances > and two exits. The entrance from to code before, and the entrance from > the return, and two exits, the exit to the following code, and an exit > to the called subroutine. > > They also see the subroutine as having many entrances, one for each call > point and an exit back towards each of the call points. > > This is mostly done by people who dislike the 'restraints' that > structure programming applies, and want to claim it doesn't really help. > > In one sense, at the very detailed machine code, the claim has some > accuracy. The key factor is that at the level of the programmers > thinking about it, a subroutine call is a light cognitive load, similar > to the other structured blocks. > The crucial point is that a block can be spaghetti code, as long as it has one point of entry and of exit. A subroutine with two returns has a hidden "goto" subroutine end, and is therefore, in structured programming terms, "spaghetti code". But it's still a block.
[toc] | [prev] | [next] | [standalone]
Page 8 of 19 — ← Prev page 1 … 6 7 [8] 9 10 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web