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 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
| 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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 14:55 +0100 |
| Message-ID | <nk0vgg$jnh$2@dont-email.me> |
| In reply to | #89413 |
On 17/06/2016 14:43, Eric Sosman wrote: > 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.) Switch statements usually have single point of exit too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 16:29 +0200 |
| Message-ID | <nk11gn$re5$1@dont-email.me> |
| In reply to | #89416 |
On 17/06/16 15:55, BartC wrote: > On 17/06/2016 14:43, Eric Sosman wrote: >> 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.) > > Switch statements usually have single point of exit too. > Most switches have "break;" statements - those are additional exit points from the switch. (IMHO, the "fall-through" between cases is a crazy idea whose major use-case could be better handled by allowing multiple values in each "case" clause. If it were not for the fall-through, there would be no need for "break" statements in most switches, and therefore usually only a single exit point.)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 15:42 +0100 |
| Message-ID | <nk128f$u6b$1@dont-email.me> |
| In reply to | #89419 |
On 17/06/2016 15:29, David Brown wrote:
> On 17/06/16 15:55, BartC wrote:
>> On 17/06/2016 14:43, Eric Sosman wrote:
>>> 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.)
>>
>> Switch statements usually have single point of exit too.
>>
>
> Most switches have "break;" statements - those are additional exit
> points from the switch.
Which breaks to the same common exit point as though there were no break
statements. So it doesn't matter whether break or fall-through is used:
X:
switch (a)
{
case b:
case c:
default:
;}
Y:
Entry is at X, and exit is at Y, unless goto or a return is used.
With other languages with Switch, which allow break from an embedded
loop for example, then it's a different story. Entry might be at X, but
it never gets to Y.
Also with C, if an If statement follows a case label, and that includes
a break, then that will upset the If statement because it the If at X,
but might not come out at Y:
switch (a)
{
case b:
X:
if (cond) {
break;
}
Y:
case c:
default:
;}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-18 20:23 +0000 |
| Message-ID | <5765acfe.30454515@news.xs4all.nl> |
| In reply to | #89419 |
David Brown <david.brown@hesbynett.no> wrote: > On 17/06/16 15:55, BartC wrote: > > Switch statements usually have single point of exit too. > > Most switches have "break;" statements - those are additional exit > points from the switch. > > (IMHO, the "fall-through" between cases is a crazy idea whose major > use-case could be better handled by allowing multiple values in each > "case" clause. If it were not for the fall-through, there would be no > need for "break" statements in most switches, and therefore usually only > a single exit point.) Erm. A switch which exits from each case through an explicit break is no different from a theoretical switch which would exit from each case through a lack of fall-through. Each has the same number of exit points, it's just that the break;s mark them explicitly. (Also, I have certainly written switches with intentional fall-through which would _not_ have worked, at least not without code repetition, without fall-through. A switch in which fall-through, rather than the lack of it, had to _but could be_ marked would be as useful, but more convenient, as the current case; a switch in which fall-through were impossible would not be good enough.) Richard
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 10:36 -0400 |
| Message-ID | <nk11uc$t2l$1@dont-email.me> |
| In reply to | #89416 |
On 6/17/2016 9:55 AM, BartC wrote:
> On 17/06/2016 14:43, Eric Sosman wrote:
>> 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.)
>
> Switch statements usually have single point of exit too.
switch (index)
{ // start of block
case 1: // first entry
...
break; // first exit
case 2: // second entry
...
break; // second exit
case 3: // third entry
...
break; // third exit
default: // fourth entry
...
break; // fourth exit
} // end of block
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 15:53 +0100 |
| Message-ID | <nk12t2$pj$1@dont-email.me> |
| In reply to | #89420 |
On 17/06/2016 15:36, Eric Sosman wrote:
> On 6/17/2016 9:55 AM, BartC wrote:
>> On 17/06/2016 14:43, Eric Sosman wrote:
>>> 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.)
>>
>> Switch statements usually have single point of exit too.
>
> switch (index)
> { // start of block
>
> case 1: // first entry
> ...
> break; // first exit
>
> case 2: // second entry
> ...
> break; // second exit
>
> case 3: // third entry
> ...
> break; // third exit
>
> default: // fourth entry
> ...
> break; // fourth exit
>
> } // end of block
>
Switch statements in C are a little peculiar. But even in your example,
all the exits end up at the common end of block.
The exact entry to the block is debatable; you might consider the
mechanism needed to execute the switch (index) to be just outside the {,
then there might be multiple entry points, or just inside it, so that
there is only one.
But when emulated with if-statements:
{
if (index==1) {
...
goto switch_end;
else if ....
switch_end:
}
then I think you would be obliged to wrap everything up in an enclosing
block, and to enter that block before starting doing tests, in case the
block in switch(index){...} had local declarations.
Then that would also be a single entry point.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 11:40 -0400 |
| Message-ID | <nk15ms$c1r$1@dont-email.me> |
| In reply to | #89424 |
On 6/17/2016 10:53 AM, BartC wrote:
> On 17/06/2016 15:36, Eric Sosman wrote:
>> On 6/17/2016 9:55 AM, BartC wrote:
>>> On 17/06/2016 14:43, Eric Sosman wrote:
>>>> 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.)
>>>
>>> Switch statements usually have single point of exit too.
>>
>> switch (index)
>> { // start of block
>>
>> case 1: // first entry
>> ...
>> break; // first exit
>>
>> case 2: // second entry
>> ...
>> break; // second exit
>>
>> case 3: // third entry
>> ...
>> break; // third exit
>>
>> default: // fourth entry
>> ...
>> break; // fourth exit
>>
>> } // end of block
>>
>
> Switch statements in C are a little peculiar. But even in your example,
> all the exits end up at the common end of block.
Let me offer a rewrite:
if (index == 1) goto case1;
if (index == 2) goto case2;
if (index == 3) goto case3;
goto defaultcase;
{
case1: ...; goto done;
case2: ...; goto done;
case3: ...; goto done;
defaultcase: ...; goto done;
}
done: ;
Clearly, the control flow is exactly the same as that of the original.
Here's the question: Is the rewrite "structured code?"
Let me also offer the words of the C Standard (which you may want
to call "peculiar," but which are the governing language, so you'd
better get used to them):
6.8.4.2p4: "A switch statement causes control to jump to, into,
or past the statement that is the /switch body/ [...]"
Note the word "into." If there is more than one case, the switch can
jump *into* the block at any of several places: any case label, or the
default label if there is one. Multiple entries, right?
6.8.6.3p2: "A break statement terminates execution of the
smallest enclosing switch or iteration statement."
Not "transfers control to the exit of the block," but "terminates."
Each break statement "terminates" the switch block. If there are
several such, there are several termination points, several points
at which control leaves the block. Multiple exits.
> The exact entry to the block is debatable; you might consider the
> mechanism needed to execute the switch (index) to be just outside the {,
> then there might be multiple entry points, or just inside it, so that
> there is only one.
The controlled block is a part of the `switch' statement (6.8.4p1).
Look at that again: The `switch' statement *contains* the block it
controls, and 6.8.4p3 even refers to the block as a "substatement."
Do you hold that the `switch' is contained within a sub-part of itself?
"Switches all the way down?"
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-17 09:30 -0700 |
| Message-ID | <e9796876-0765-48d7-bf2c-ee91d25018e7@googlegroups.com> |
| In reply to | #89427 |
On Friday, June 17, 2016 at 10:41:25 AM UTC-5, Eric Sosman wrote: > Let me offer a rewrite: > > if (index == 1) goto case1; > if (index == 2) goto case2; > if (index == 3) goto case3; ... If none of the case labels are within loops, the above code would be equivalent to replacing each "goto caseX" with the contents of the code between the appropriate case label and either the break that would exit the switch, if not within an "if" block. If an "if" statement has a break within one side, then all code which could execute after the "if" (if any) should be copied into the places where it could execute. As such, using "switch" in that way would not violate structured programming. The messy situation occurs when a goto is used to enter a language-defined loop or a loop created with goto statements. In that scenario, the amount of code that might need to copied out to "flatten" the structure may not be bounded.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 17:41 +0100 |
| Message-ID | <nk198i$q3t$1@dont-email.me> |
| In reply to | #89427 |
On 17/06/2016 16:40, Eric Sosman wrote:
> On 6/17/2016 10:53 AM, BartC wrote:
>> Switch statements in C are a little peculiar. But even in your example,
>> all the exits end up at the common end of block.
>
> Let me offer a rewrite:
>
> if (index == 1) goto case1;
> if (index == 2) goto case2;
> if (index == 3) goto case3;
> goto defaultcase;
> {
> case1: ...; goto done;
> case2: ...; goto done;
> case3: ...; goto done;
> defaultcase: ...; goto done;
> }
> done: ;
>
> Clearly, the control flow is exactly the same as that of the original.
> Here's the question: Is the rewrite "structured code?"
Only if you can take any program, replace all the ifs, whiles, fors and
all other constructs into goto equivalents, and say the result is still
structured code.
You're delving here into implementation details which is always going to
end up as a set of jumps at some point.
Considered at a higher level, a switch statement, even C's crude version
which is capable of much abuse, can be used as a black box programming
construct with one entry and one exit. (Subject to embedded gotos,
returns, long jmps just like every other kind of statement.)
(Also your switch example, without or without breaks, could be rewritten
as a set of if-statements without recourse to goto.)
> Let me also offer the words of the C Standard (which you may want
> to call "peculiar," but which are the governing language, so you'd
> better get used to them):
>
> 6.8.4.2p4: "A switch statement causes control to jump to, into,
> or past the statement that is the /switch body/ [...]"
>
> Note the word "into." If there is more than one case, the switch can
> jump *into* the block at any of several places: any case label, or the
> default label if there is one. Multiple entries, right?
Possibly. Consider this version:
switch (index)
{ char buffer[4096];
case 1: ....
....
If this requires some block entry code to allocate that array, then
there might need to be common code to do that. But whatever happens, you
will usually need to enter the block via the single switch construct.
( You can have a block of N apartments each with their own front doors.
But if they all share the same main entrance on the ground floor, and a
back entrance, then you only need two operatives to keep watch for a
suspect rather than N.)
>> The exact entry to the block is debatable; you might consider the
>> mechanism needed to execute the switch (index) to be just outside the {,
>> then there might be multiple entry points, or just inside it, so that
>> there is only one.
>
> The controlled block is a part of the `switch' statement (6.8.4p1).
> Look at that again: The `switch' statement *contains* the block it
> controls, and 6.8.4p3 even refers to the block as a "substatement."
> Do you hold that the `switch' is contained within a sub-part of itself?
> "Switches all the way down?"
Then the entry point is the switch as I mentioned above. One operative.
Or one breakpoint in a debugger.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 08:11 -0700 |
| Message-ID | <1169ded1-6265-4a52-98e2-340ddc4cc87f@googlegroups.com> |
| In reply to | #89420 |
On Friday, June 17, 2016 at 3:37:10 PM UTC+1, Eric Sosman wrote:
>
> > Switch statements usually have single point of exit too.
>
> switch (index)
> { // start of block
>
> case 1: // first entry
> ...
> break; // first exit
>
> case 2: // second entry
> ...
> break; // second exit
>
> case 3: // third entry
> ...
> break; // third exit
>
> default: // fourth entry
> ...
> break; // fourth exit
>
> } // end of block
>
>
Yes, the internals of the switch block do not meet the criteria for
structured programming. But the block itself is a block.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 11:59 -0400 |
| Message-ID | <nk16ph$gbv$1@dont-email.me> |
| In reply to | #89425 |
On 6/17/2016 11:11 AM, Malcolm McLean wrote:
>
> Yes, the internals of the switch block do not meet the criteria for
> structured programming.
Okay, Malcolm-structure forbids the `switch'. (And, as has been
pointed out elsethread, the `while', `for', and `do..while' statements.
Also recursion.
> But the block itself is a block.
What has that to do with anything? Does wrapping a { } pair
around un-Mal-structured code somehow make it more Mal-structured?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 09:52 -0700 |
| Message-ID | <d3c0ffd6-23b8-4a2b-952d-bcd8cf763619@googlegroups.com> |
| In reply to | #89429 |
On Friday, June 17, 2016 at 4:59:53 PM UTC+1, Eric Sosman wrote:
> On 6/17/2016 11:11 AM, Malcolm McLean wrote:
> >
> > Yes, the internals of the switch block do not meet the criteria for
> > structured programming.
>
> Okay, Malcolm-structure forbids the `switch'. (And, as has been
> pointed out elsethread, the `while', `for', and `do..while' statements.
> Also recursion.
>
> > But the block itself is a block.
>
> What has that to do with anything? Does wrapping a { } pair
> around un-Mal-structured code somehow make it more Mal-structured?
>
The code must enter at the "switch" line.
So we can say that there is a dummy null statement at the start of the block
which is always executed. Then control always returns to the point below block end.
So it meets the external criteria for a "block" - one point of entry, one point of
exit.
But it's not internally a structured block. Because there's a multi-way jump
to the cases. That's not allowed. Only binary forks are allowed.
However we could convert it to a structured block using nested ifs.
Then you can draw it out using the plastic stencil I was give age 11,
and all the cases become blocks.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 18:24 +0100 |
| Message-ID | <4nW8z.35380$z63.30061@fx42.am4> |
| In reply to | #89432 |
On 17/06/2016 17:52, Malcolm McLean wrote: > But it's not internally a structured block. Because there's a multi-way jump > to the cases. That's not allowed. Only binary forks are allowed. Why, what's wrong with a multi-way jump? In this paper by Dijkstra: https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF on page 28 (p.24 on the page itself), he shows a diagram of an N-way case statement with one entry and exit that he considers structured. (Such a case statement is like a switch statement with cases 1 to N.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 14:33 -0400 |
| Message-ID | <nk1fq9$jcs$1@dont-email.me> |
| In reply to | #89432 |
On 6/17/2016 12:52 PM, Malcolm McLean wrote:
> On Friday, June 17, 2016 at 4:59:53 PM UTC+1, Eric Sosman wrote:
>> On 6/17/2016 11:11 AM, Malcolm McLean wrote:
>>>
>>> Yes, the internals of the switch block do not meet the criteria for
>>> structured programming.
>>
>> Okay, Malcolm-structure forbids the `switch'. (And, as has been
>> pointed out elsethread, the `while', `for', and `do..while' statements.
>> Also recursion.
>>
>>> But the block itself is a block.
>>
>> What has that to do with anything? Does wrapping a { } pair
>> around un-Mal-structured code somehow make it more Mal-structured?
>>
> The code must enter at the "switch" line.
The block is not entered at the `switch', which is outside the
block. The block is entered at the chosen `case' or `default' (or
is skipped altogether).
> So we can say that there is a dummy null statement at the start of the block
> which is always executed.
Why not say there are three such? Plus another pair of null's
at the beginning and end of each case (they're always executed, whether
the cases are selected or not). Why not say that flying angels blow
the planets in their courses?
> Then control always returns to the point below block end.
> So it meets the external criteria for a "block" - one point of entry, one point of
> exit.
It's valid to say that the control flow reaches a point just before
the block, and (barring other diversions) eventually reaches a point
after the block. But so what? You could say the same about a function
that consists of a twisty little maze of undisciplined `goto's, but that
doesn't say anything about whether the code is or isn't structured.
> But it's not internally a structured block. Because there's a multi-way jump
> to the cases. That's not allowed. Only binary forks are allowed.
Was that a Supreme Court decision, or a law passed by Congress?
> However we could convert it to a structured block using nested ifs.
> Then you can draw it out using the plastic stencil I was give age 11,
> and all the cases become blocks.
... except for those that fall through. Oh, right, you've already
"cured" problems of that sort by stamping out N identical copies of
bits and pieces of code. Good use for a stencil.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-17 12:57 -0700 |
| Message-ID | <455a6e16-d0e0-4234-94ee-5cf83e5748c0@googlegroups.com> |
| In reply to | #89439 |
On Friday, June 17, 2016 at 7:33:54 PM UTC+1, Eric Sosman wrote: > > It's valid to say that the control flow reaches a point just before > the block, and (barring other diversions) eventually reaches a point > after the block. But so what? You could say the same about a function > that consists of a twisty little maze of undisciplined `goto's, but that > doesn't say anything about whether the code is or isn't structured. > Exactly. So such a block is not, internally, a structured block. But externally that doesn't matter. > > ... except for those that fall through. Oh, right, you've already > "cured" problems of that sort by stamping out N identical copies of > bits and pieces of code. Good use for a stencil. > The stencil had a diamond. Control always enters at the top of the diamond. The diamond can't do anything. It simply creates a branch, based on some criterion of other. Observant readers will note that there are three potential exits. One was always unused. This gave a bit of flexibility when drawing the flow chart. You could invent a multi-branching stencil. But in fact there wasn't one.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 16:12 -0400 |
| Message-ID | <nk1lk3$99b$1@dont-email.me> |
| In reply to | #89450 |
On 6/17/2016 3:57 PM, Malcolm McLean wrote:
> On Friday, June 17, 2016 at 7:33:54 PM UTC+1, Eric Sosman wrote:
>>
>> It's valid to say that the control flow reaches a point just before
>> the block, and (barring other diversions) eventually reaches a point
>> after the block. But so what? You could say the same about a function
>> that consists of a twisty little maze of undisciplined `goto's, but that
>> doesn't say anything about whether the code is or isn't structured.
>>
> Exactly.
> So such a block is not, internally, a structured block.
> But externally that doesn't matter.
>>
>> ... except for those that fall through. Oh, right, you've already
>> "cured" problems of that sort by stamping out N identical copies of
>> bits and pieces of code. Good use for a stencil.
>>
> The stencil had a diamond. Control always enters at the top of
> the diamond. The diamond can't do anything. It simply creates
> a branch, based on some criterion of other.
>
> Observant readers will note that there are three potential exits.
> One was always unused. This gave a bit of flexibility when drawing
> the flow chart.
>
> You could invent a multi-branching stencil. But in fact there wasn't
> one.
Here speaks someone who never encountered FORTRAN ...
IF (X) 100, 200, 300
... means "Go to statement label 100 if X is negative, 200 if X
is zero, 300 if X is positive." There you are: Three-way branch.
Control flows into the diamond at the top vertex, and exits through
the bottom or through either side. (It's been years and years
since I last drew a flowchart, but in the late 1960's I definitely
had occasion to use all four vertices.)
Most of the time there were only two unique destinations:
"Positive or non-positive?"
IF (X) 100, 100, 300
"Negative or non-negative?"
IF (X) 100, 300, 300
"Zero or non-zero?"
IF (X) 100, 200, 100
... but every now and again there'd be three distinct targets.
This was handy in binary search ("search to the left, or search
to the right, or GOTCHA") and also in heap management ("examine
both children, or the only child, or nothing because we've reached
a leaf of the heap").
What I *never* saw was the completely vacuous three-way IF:
"I'll think about it later ..."
IF (X) 100, 100, 100
... but maybe there's an IOFCC somewhere.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-06-18 09:16 +1200 |
| Message-ID | <dsj7loF4umpU2@mid.individual.net> |
| In reply to | #89432 |
On 06/18/16 04:52 AM, Malcolm McLean wrote:
> On Friday, June 17, 2016 at 4:59:53 PM UTC+1, Eric Sosman wrote:
>> On 6/17/2016 11:11 AM, Malcolm McLean wrote:
>>>
>>> Yes, the internals of the switch block do not meet the criteria for
>>> structured programming.
>>
>> Okay, Malcolm-structure forbids the `switch'. (And, as has been
>> pointed out elsethread, the `while', `for', and `do..while' statements.
>> Also recursion.
>>
>>> But the block itself is a block.
>>
>> What has that to do with anything? Does wrapping a { } pair
>> around un-Mal-structured code somehow make it more Mal-structured?
>>
> The code must enter at the "switch" line.
> So we can say that there is a dummy null statement at the start of the block
> which is always executed. Then control always returns to the point below block end.
> So it meets the external criteria for a "block" - one point of entry, one point of
> exit.
By that logic a function with multiple returns also meets the criteria:
control always ends up at the point below the call.
--
Ian
[toc] | [prev] | [next] | [standalone]
Page 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web