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-08-14 01:32 -0400 |
| Articles | 20 on this page of 382 — 26 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 Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-19 09:49 -0700
Re: Small Device C Compiler 3.6.0 released supercat@casperkitty.com - 2016-07-19 15:14 -0700
Re: Small Device C Compiler 3.6.0 released Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 09:20 -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 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 10:52 -0700
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 16:03 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 22:28 -0500
Re: Small Device C Compiler 3.6.0 released Gareth Owen <gwowen@gmail.com> - 2016-07-05 07:11 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-05 02:06 -0700
Re: Small Device C Compiler 3.6.0 released Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-06 15:12 +0100
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:29 -0700
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 13:54 -0500
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-04 07:18 +0200
Re: Small Device C Compiler 3.6.0 released Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-04 01:58 -0700
Re: Small Device C Compiler 3.6.0 released Rosario19 <Ros@invalid.invalid> - 2016-07-16 19:37 +0200
Re: Small Device C Compiler 3.6.0 released "D. Aaron Sawyer" <aaron@110.net> - 2016-07-16 15:58 -0300
Re: Small Device C Compiler 3.6.0 released Ike Naar <ike@iceland.freeshell.org> - 2016-07-16 19:25 +0000
Re: Small Device C Compiler 3.6.0 released Martin Shobe <mashobe9@gmail.com> - 2016-07-04 12:10 -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
Re: Small Device C Compiler 3.6.0 released bitrex <bitrex@de.lete.earthlink.net> - 2016-08-14 01:32 -0400
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-04 16:03 -0700 |
| Message-ID | <2c8ffe2c-2951-43eb-89db-36ba2453a825@googlegroups.com> |
| In reply to | #90002 |
On Monday, July 4, 2016 at 7:54:54 PM UTC+1, Martin Shobe wrote: > On 7/4/2016 12:52 PM, Malcolm McLean wrote: > > This appears to contradict the claim you made that was under contention. > As a reminder, you claimed that the following restriction followed from > the single entry/exit restriction. Are you now retracting that claim? > Elaborating on it. A program typically has a single point of entry and of exit - even if multiple "exit()" calls are littered round the source, they all lead back to a cleanup routine which returns control to the shell or windowing system. So a program is a "block", in structured programming terms. However it need not consist of "blocks" internally. If it does, however, then they must be arranged in a tree (with a special case for recursion). Control must enter at the root of the local branch, then return to that point. However we can declare any node to be a "spaghetti-code black box" as long as it obeys the single entry / single exit restriction. ' If you've got a one dimensional space, and the space as a whole is an entity, and it contains a number of other entities, and we have the restriction that entities cannot partially overlap, but they can nest, you necessarily get a tree.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-07-04 22:28 -0500 |
| Message-ID | <nlf9hd$hhm$1@dont-email.me> |
| In reply to | #90006 |
On 7/4/2016 6:03 PM, Malcolm McLean wrote: > On Monday, July 4, 2016 at 7:54:54 PM UTC+1, Martin Shobe wrote: >> On 7/4/2016 12:52 PM, Malcolm McLean wrote: >> >> This appears to contradict the claim you made that was under contention. >> As a reminder, you claimed that the following restriction followed from >> the single entry/exit restriction. Are you now retracting that claim? >> > Elaborating on it. Your elaboration appears to contradict it. Remember what your claim was. That the other parts of structured programming follow from single entry/exit. If the internal structure doesn't follow from single entry/exit, as your "elaboration" appears to say, then it there are parts of structured programming that doesn't follow from single entry/exit. So are you now retracting that claim? > A program typically has a single point of entry and of exit - even > if multiple "exit()" calls are littered round the source, they all > lead back to a cleanup routine which returns control to the shell > or windowing system. So a program is a "block", in structured > programming terms. > However it need not consist of "blocks" internally. If it does, > however, then they must be arranged in a tree (with a special case > for recursion). Control must enter at the root of the local branch, > then return to that point. > However we can declare any node to be a "spaghetti-code black box" > as long as it obeys the single entry / single exit restriction. ' > > If you've got a one dimensional space, and the space as a whole is > an entity, and it contains a number of other entities, and we > have the restriction that entities cannot partially overlap, > but they can nest, you necessarily get a tree. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-05 07:11 +0100 |
| Message-ID | <87inwkwr5f.fsf@gmail.com> |
| In reply to | #90014 |
Martin Shobe <mashobe9@gmail.com> writes: > On 7/4/2016 6:03 PM, Malcolm McLean wrote: >> On Monday, July 4, 2016 at 7:54:54 PM UTC+1, Martin Shobe wrote: >>> On 7/4/2016 12:52 PM, Malcolm McLean wrote: >>> >>> This appears to contradict the claim you made that was under contention. >>> As a reminder, you claimed that the following restriction followed from >>> the single entry/exit restriction. Are you now retracting that claim? >>> >> Elaborating on it. > > Your elaboration appears to contradict it. Colour me amazed.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-05 02:06 -0700 |
| Message-ID | <5f92c265-e2e5-45ce-913b-fa0b7bfac8ca@googlegroups.com> |
| In reply to | #90014 |
On Tuesday, July 5, 2016 at 4:28:56 AM UTC+1, Martin Shobe wrote: > On 7/4/2016 6:03 PM, Malcolm McLean wrote: > > On Monday, July 4, 2016 at 7:54:54 PM UTC+1, Martin Shobe wrote: > >> On 7/4/2016 12:52 PM, Malcolm McLean wrote: > >> > >> This appears to contradict the claim you made that was under contention. > >> As a reminder, you claimed that the following restriction followed from > >> the single entry/exit restriction. Are you now retracting that claim? > >> > > Elaborating on it. > > Your elaboration appears to contradict it. Remember what your claim was. > That the other parts of structured programming follow from single > entry/exit. If the internal structure doesn't follow from single > entry/exit, as your "elaboration" appears to say, then it there are > parts of structured programming that doesn't follow from single > entry/exit. So are you now retracting that claim? > I can't remember exactly what I said, and I might have misspoken. But my understanding of what structured programming is remains the same. The "structure" to which a "structured program" refers to is a structure of blocks. a "block", in structured programming jargon, is a unit of code which has one point of entry and one point of exit. Now a non-branching machine instruction is a "block", and there are special rules for branches. The special rules, other than recursion, do not however affect the nesting quality of blocks. A programming written rigourously according to the structured programming paradigm consists of blocks, the special rules, and only blocks, right the way down the the machine instructions. However it is a robust paradigm. A block does not have to be written according to structured programming rules internally, as long as it obeys the single point of entry, single point of exit rule. A program which consists of blocks, some of which are spaghetti code internally, is a partially structured program - the program as a whole is structured, but we have to treat the spaghetti code blocks as black boxes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-06 15:12 +0100 |
| Message-ID | <87wpky6ek3.fsf@bsb.me.uk> |
| In reply to | #90017 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > I can't remember exactly what I said, and I might have misspoken. But my > understanding of what structured programming is remains the same. > > The "structure" to which a "structured program" refers to is a structure of > blocks. a "block", in structured programming jargon, is a unit of code > which has one point of entry and one point of exit. > Now a non-branching machine instruction is a "block", and there are special > rules for branches. The special rules, other than recursion, do not however > affect the nesting quality of blocks. Neither does recursion. A recursive call nests the function body in exactly the same way as any other function call. You've decided you want recursion to be an exception so you ignore this run-time nesting. > A programming written rigourously > according to the structured programming paradigm consists of blocks, > the special rules, and only blocks, right the way down the the machine > instructions. No. It is blocks right down to whatever the primitive statements of the language are. These are very unlikely to correspond to machine instructions, but whether they compile to structured machine code is neither here nor there for the structure of the high-level language code. > However it is a robust paradigm. A block does not have to be written > according to structured programming rules internally, as long as it obeys > the single point of entry, single point of exit rule. A program which consists > of blocks, some of which are spaghetti code internally, is a partially > structured program - the program as a whole is structured, but we have > to treat the spaghetti code blocks as black boxes. That rather defeats the main purpose of the structured programming movement. The intent was to eliminate the spaghetti code, not just brush it under a structured blanket. Structured programming has become the norm -- no one writes spaghetti code anymore. Some people are happy to relax the rules a bit (break, early returns and so on) but that's very far from spaghetti. These are tolerated because a secondary goal of structured programming -- that programs should be easy to argue about formally -- has all but been abandoned. The constant stream of code vulnerabilities that get posted suggest that it may have been a mistake to abandon it, but I don't see much appetite from programmers for code whose correctness and safety are easy to verify. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-06 08:29 -0700 |
| Message-ID | <0bdaea52-b267-4f09-8696-e7435b739b0e@googlegroups.com> |
| In reply to | #90080 |
On Wednesday, July 6, 2016 at 3:12:44 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Now a non-branching machine instruction is a "block", and there are special > > rules for branches. The special rules, other than recursion, do not however > > affect the nesting quality of blocks. > > Neither does recursion. A recursive call nests the function body in > exactly the same way as any other function call. You've decided you > want recursion to be an exception so you ignore this run-time nesting. > No it doesn't. It nests the block within itself. If the depth is known at compile time, we can expand out the calls and declare all the blocks to be different nodes, and we're back to the tree. But generally you use recursion because depth isn't known at compile time. > > No. It is blocks right down to whatever the primitive statements of the > language are. These are very unlikely to correspond to machine > instructions, but whether they compile to structured machine code is > neither here nor there for the structure of the high-level language code. > Fair enough. However a machine code instruction that doesn't branch is a block, and you can't drill down any further. > > > However it is a robust paradigm. A block does not have to be written > > according to structured programming rules internally, as long as it obeys > > the single point of entry, single point of exit rule. A program which consists > > of blocks, some of which are spaghetti code internally, is a partially > > structured program - the program as a whole is structured, but we have > > to treat the spaghetti code blocks as black boxes. > > That rather defeats the main purpose of the structured programming > movement. The intent was to eliminate the spaghetti code, not just > brush it under a structured blanket. > There's a tendency for people who propose ideas to become fanatical, and demand perfect adherence. > > Structured programming has become the norm -- no one writes spaghetti > code anymore. Some people are happy to relax the rules a bit (break, > early returns and so on) but that's very far from spaghetti. These are > tolerated because a secondary goal of structured programming -- that > programs should be easy to argue about formally -- has all but been > abandoned. The constant stream of code vulnerabilities that get posted > suggest that it may have been a mistake to abandon it, but I don't see > much appetite from programmers for code whose correctness and safety are > easy to verify. > I think there's a lot of truth in that. But the other reason is that in languages like C, subroutines are "blocks". Whilst you can stick in an early return, you can't return to a different point in caller. Whilst you can type the command "goto", you can't jump outside the subroutine itself.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-07-04 13:54 -0500 |
| Message-ID | <nlebdh$7j6$1@dont-email.me> |
| In reply to | #90002 |
On 7/4/2016 12:52 PM, Malcolm McLean wrote: > On Monday, July 4, 2016 at 6:10:35 PM UTC+1, Martin Shobe wrote: >> >> This discussion is about structured programming. In particular this >> question is about the claim that the limitations on the internal >> structure of blocks follow from single entry/exit. A claim that Malcolm >> made and then appeared to be contradicting. >> > A block has a single point of entry and of exit. > So if you have a program which consists of two blocks they can concatenate, > or nest, but they cannot overlap. However internally the blocks need not > be structured. This appears to contradict the claim you made that was under contention. As a reminder, you claimed that the following restriction followed from the single entry/exit restriction. Are you now retracting that claim? > A structured program places the additional requirement that blocks consist > solely of blocks and selections (if), loops (backwards jumps controlled by an if), > and recursive calls. > Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-07-04 07:18 +0200 |
| Message-ID | <85sjnbl85aqiccn760lvd6ba5gs8alqr91@4ax.com> |
| In reply to | #89603 |
On Sun, 19 Jun 2016 00:17:43 -0500, Martin Shobe wrote: >Is that a retraction of your claim that it does? the key point is not structured programming but readable programming for me can be possible one routine readable not structured where structured means: each block can have only one point of enter one point of exit etc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-04 01:58 -0700 |
| Message-ID | <52dad5ec-56a5-4df0-8df8-9ce17082ce25@googlegroups.com> |
| In reply to | #90004 |
On Monday, July 4, 2016 at 6:18:19 AM UTC+1, Rosario19 wrote: > > >Is that a retraction of your claim that it does? > > the key point is not structured programming > but readable programming > > for me can be possible one routine readable not structured > > where structured means: each block can have only one point of enter > one point of exit etc > Exactly. Structured programming is one method for organising code. If you don't use it, the result is not necessarily "spaghetti code", but code structured according to a different convention. However structured programming has really caught on and been successful.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-07-16 19:37 +0200 |
| Message-ID | <arrkob1h5mjmm10kq6rhad9fe2eackfkbl@4ax.com> |
| In reply to | #90012 |
On Mon, 4 Jul 2016 01:58:42 -0700 (PDT), Malcolm McLean wrote:
>On Monday, July 4, 2016 at 6:18:19 AM UTC+1, Rosario19 wrote:
>>
>> >Is that a retraction of your claim that it does?
>>
>> the key point is not structured programming
>> but readable programming
>>
>> for me can be possible one routine readable not structured
>>
>> where structured means: each block can have only one point of enter
>> one point of exit etc
>>
>Exactly.
>Structured programming is one method for organising code. If you don't use
>it, the result is not necessarily "spaghetti code", but code structured
>according to a different convention.
>However structured programming has really caught on and been successful.
if one make to the level of instruction the box...
each box has its 1 entry level and 1 exit level
if you make the box the follow routine
int f(int a)
{
//--------------- box
if(a<0||(a+1)<=0) return -1;
a=a+1;
return a;
//---------------
}
this has 1 entry but 2 exit: one for error case and one for common
return the result
[toc] | [prev] | [next] | [standalone]
| From | "D. Aaron Sawyer" <aaron@110.net> |
|---|---|
| Date | 2016-07-16 15:58 -0300 |
| Message-ID | <nme04r$ogn$1@dont-email.me> |
| In reply to | #90453 |
On 2016.07.16 14:37, Rosario19 wrote:
> On Mon, 4 Jul 2016 01:58:42 -0700 (PDT), Malcolm McLean wrote:
>
>> On Monday, July 4, 2016 at 6:18:19 AM UTC+1, Rosario19 wrote:
>>>
>>>> Is that a retraction of your claim that it does?
>>>
>>> the key point is not structured programming
>>> but readable programming
>>>
>>> for me can be possible one routine readable not structured
>>>
>>> where structured means: each block can have only one point of enter
>>> one point of exit etc
>>>
>> Exactly.
>> Structured programming is one method for organising code. If you don't use
>> it, the result is not necessarily "spaghetti code", but code structured
>> according to a different convention.
>> However structured programming has really caught on and been successful.
>
> if one make to the level of instruction the box...
>
> each box has its 1 entry level and 1 exit level
>
> if you make the box the follow routine
>
> int f(int a)
> {
> //--------------- box
> if(a<0||(a+1)<=0) return -1;
> a=a+1;
> return a;
> //---------------
> }
>
> this has 1 entry but 2 exit: one for error case and one for common
> return the result
>
The 'structured' version would have 1 entry and 1 exit:
int f(int a)
{
//------------------ box
int res = -1;
if (!( a<0 || (a+1)<=0 )) res = a+1;
return res;
//------------------
}
Without the 'res' variable:
int f(int a)
{
//------------------ box
return ( a<0 || (a+1)<=0 ) ? -1 : a+1;
//------------------
}
Simplifying the logic (since a<0 is equivalent to (a+1)<=0 for all integer a):
int f(int a)
{
//------------------ box
return ( a<0 ) ? -1 : a+1;
//------------------
}
In most cases, the 2 exit form can be restructured to single exit, but additional storage of result value(s) or internal
state (flag(s)) will be needed.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-16 19:25 +0000 |
| Message-ID | <slrn3vfsnol2g6.ds8.ike@iceland.freeshell.org> |
| In reply to | #90453 |
On 2016-07-16, Rosario19 <Ros@invalid.invalid> wrote: > if(a<0||(a+1)<=0) return -1; > a=a+1; > return a; return a<0 ? -1 : a+1;
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-07-04 12:10 -0500 |
| Message-ID | <nle5a0$cnp$1@dont-email.me> |
| In reply to | #90004 |
On 7/4/2016 12:18 AM, Rosario19 wrote: > On Sun, 19 Jun 2016 00:17:43 -0500, Martin Shobe wrote: > >> Is that a retraction of your claim that it does? > > the key point is not structured programming > but readable programming This discussion is about structured programming. In particular this question is about the claim that the limitations on the internal structure of blocks follow from single entry/exit. A claim that Malcolm made and then appeared to be contradicting. 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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-06-19 08:23 -0400 |
| Message-ID | <u9w9z.959$XP6.808@fx01.iad> |
| In reply to | #89602 |
On 6/19/16 12:06 AM, Malcolm McLean wrote: > 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. > A Block with 'Spaghetti Code' is NOT a Structured Block. That is the whole basic of structured code, that it can be fundamentally broken down into just the Structured Elements. Any Code can be broken down in some degree to Blocks, as the program as a whole is a block. There is some use for the concept of 'Mostly Structured Code' which allows for most of the code to be built on the principles of Structure, but contain a limited number, and well documented, Unstructured 'Black Boxes' that are well defined Input/Output, these Black Boxes needing to be shown correct outside the domain of principles of Structured Code.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-06-18 14:30 -0500 |
| Message-ID | <t28bmbdlv5oblk3fhh1093u0tk73jl46cg@4ax.com> |
| In reply to | #89533 |
On Sat, 18 Jun 2016 10:35:41 -0400, Richard Damon
<Richard@Damon-Family.org> 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)
>* 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.
Certainly structure programming is as applicable to assembler as is is
to any HLL. (Modern) HLLs given you the tools for doing it simply,
without having to build the bits and pieces yourself. That's
analogous to OOP - you can certainly do OOP in C, but C++ provides a
bunch of tools for expressing the structures directly.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 09:43 -0400 |
| Message-ID | <nk0ur5$i0j$1@dont-email.me> |
| In reply to | #89406 |
On 6/17/2016 9:12 AM, Martin Shobe wrote:
> On 6/17/2016 7:29 AM, Malcolm McLean wrote:
>> [...]
>> If you read the article carefully you'll see that the structure of
>> structured
>> programming is as I described.
> [...]
>> Blocks containing a single point of entry
>> and a sigle point of exit, which can be expanded to contain other blocks
>> with the same characteristics.
So, structured code must avoid the `switch' statement?
(I guess a `switch' with one and only one case is okay.)
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web