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 3 of 19 — ← Prev page 1 2 [3] 4 5 … 19 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-14 16:32 +0100 |
| Message-ID | <njp82b$mlf$1@dont-email.me> |
| In reply to | #89073 |
On 14/06/16 16:15, BartC wrote: > On 14/06/2016 15:44, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 14/06/2016 13:38, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>>> And why not? >>> >>>> And since you write letters to named things in programs you need a >>>> postal address for them. >>> >>> Actually this is pretty much what happens in the languages I >>> implement. To illustrate in C syntax (but it won't work in C): >> >> But you were talking about C, weren't you? Your complaint and your >> justification of it were about C, I thought. If not, I would have left >> it alone. > > > I don't want to get into a discussion about a private language > > The concept is universal. It doesn't matter whether C allows such things > or not. Uh, yes it does. If C doesn't allow it, it's neither universal nor topical. Such a discussion might fit better into comp.programming. <snip> > You can't just dismiss every other way of doing something just because > it's 'not C'. Not in comp.programming, he can't. But here, he can. > Sometimes those other ways are better! Maybe, maybe not, but that doesn't make them topical here. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-14 22:09 +0100 |
| Message-ID | <njprqd$57u$1@dont-email.me> |
| In reply to | #89074 |
On 14/06/2016 16:32, Richard Heathfield wrote: > On 14/06/16 16:15, BartC wrote: >> The concept is universal. It doesn't matter whether C allows such things >> or not. > > Uh, yes it does. If C doesn't allow it, it's neither universal nor > topical. Such a discussion might fit better into comp.programming. The discussion has touched on the pros and cons of C's block-scope model. That would necessarily require some reference to something outside the language otherwise you can't have a pro or a con; something just 'is', without question. However, the problem of pinpointing a particular name instance in a function can sometimes occur within the language too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-14 14:48 -0700 |
| Message-ID | <lnmvmn1lxj.fsf@kst-u.example.com> |
| In reply to | #89095 |
BartC <bc@freeuk.com> writes:
> On 14/06/2016 16:32, Richard Heathfield wrote:
>> On 14/06/16 16:15, BartC wrote:
>>> The concept is universal. It doesn't matter whether C allows such things
>>> or not.
>>
>> Uh, yes it does. If C doesn't allow it, it's neither universal nor
>> topical. Such a discussion might fit better into comp.programming.
>
> The discussion has touched on the pros and cons of C's block-scope model.
>
> That would necessarily require some reference to something outside the
> language otherwise you can't have a pro or a con; something just 'is',
> without question.
>
> However, the problem of pinpointing a particular name instance in a
> function can sometimes occur within the language too.
Local variables in recursive functions, even if all scopes have names of
some sort, cannot be uniquely referred to without runtime information.
You can have two or more distinct objects, both created by the same
declaration, both existing at the same time.
(In practice, the fact that some scopes are anonymous has never been much
of a problem for me.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-14 23:05 +0100 |
| Message-ID | <njpv35$jqv$1@dont-email.me> |
| In reply to | #89105 |
On 14/06/2016 22:48, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 14/06/2016 16:32, Richard Heathfield wrote: >>> On 14/06/16 16:15, BartC wrote: >>>> The concept is universal. It doesn't matter whether C allows such things >>>> or not. >>> >>> Uh, yes it does. If C doesn't allow it, it's neither universal nor >>> topical. Such a discussion might fit better into comp.programming. >> >> The discussion has touched on the pros and cons of C's block-scope model. >> >> That would necessarily require some reference to something outside the >> language otherwise you can't have a pro or a con; something just 'is', >> without question. >> >> However, the problem of pinpointing a particular name instance in a >> function can sometimes occur within the language too. > > Local variables in recursive functions, even if all scopes have names of > some sort, cannot be uniquely referred to without runtime information. > You can have two or more distinct objects, both created by the same > declaration, both existing at the same time. > > (In practice, the fact that some scopes are anonymous has never been much > of a problem for me.) By 'name instance' I meant resolving which of the several declarations of 'A' there might be in a function. The multiple instances of each created by recursive calls is another matter. (And block scope rules also apply to statics, typedefs, structs, and enums.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-14 15:12 -0700 |
| Message-ID | <eb6d9faa-25a4-47c3-a322-a69b349ee930@googlegroups.com> |
| In reply to | #89105 |
On Tuesday, June 14, 2016 at 4:48:45 PM UTC-5, Keith Thompson wrote: > Local variables in recursive functions, even if all scopes have names of > some sort, cannot be uniquely referred to without runtime information. > You can have two or more distinct objects, both created by the same > declaration, both existing at the same time. A simple compiler targeting a typical stack-based machine can assign a stack-relative or frame-relative address to each local variable when it processes the declaration. A compiler needs to keep track of which addresses are stack-relative and which ones aren't, but beyond that the compiler can treat the current function's stack frame as though it's the only one in the universe. Fancier approaches may enable a compiler to generate more efficient code, but the stack-frame based approach makes it possible to produce decent code on many platforms using either a single-pass compiler feeding a two- pass assembler, or else a single-pass compiler that generates code directly but applies fix-ups afterward.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-14 23:16 -0700 |
| Message-ID | <eec9862e-4c05-428e-af89-72689e936818@googlegroups.com> |
| In reply to | #89105 |
On Tuesday, June 14, 2016 at 10:48:45 PM UTC+1, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > > On 14/06/2016 16:32, Richard Heathfield wrote: > >> On 14/06/16 16:15, BartC wrote: > >>> The concept is universal. It doesn't matter whether C allows such things > >>> or not. > >> > >> Uh, yes it does. If C doesn't allow it, it's neither universal nor > >> topical. Such a discussion might fit better into comp.programming. > > > > The discussion has touched on the pros and cons of C's block-scope model. > > > > That would necessarily require some reference to something outside the > > language otherwise you can't have a pro or a con; something just 'is', > > without question. > > > > However, the problem of pinpointing a particular name instance in a > > function can sometimes occur within the language too. > > Local variables in recursive functions, even if all scopes have names of > some sort, cannot be uniquely referred to without runtime information. > You can have two or more distinct objects, both created by the same > declaration, both existing at the same time. > > (In practice, the fact that some scopes are anonymous has never been much > of a problem for me.) > Yes, recursion makes programs harder to explain, understand, follow and debug. It's an exception to structured programming in many ways, including that scope becomes more complicated. However it's hard to do without for some situations.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-15 07:45 +0100 |
| Message-ID | <njqtim$v1i$1@dont-email.me> |
| In reply to | #89130 |
On 15/06/16 07:16, Malcolm McLean wrote: > On Tuesday, June 14, 2016 at 10:48:45 PM UTC+1, Keith Thompson wrote: <snip> >> >> Local variables in recursive functions, even if all scopes have names of >> some sort, cannot be uniquely referred to without runtime information. >> You can have two or more distinct objects, both created by the same >> declaration, both existing at the same time. >> >> (In practice, the fact that some scopes are anonymous has never been much >> of a problem for me.) >> > Yes, recursion makes programs harder to explain, understand, follow > and debug. Your "yes" makes it sound like you're agreeing with Keith, but he didn't say that recursion makes programs harder to explain, understand, follow or debug. In fact, recursion undoubtedly makes /some/ programs harder to explain etc, but equally undoubtedly it makes some programs /easier/ to explain etc. > It's an exception to structured programming in many ways, including > that scope becomes more complicated. However it's hard to do without > for some situations. I don't see why you think scope becomes more complicated when a function calls itself than when it calls some other function. The same rules apply in each case. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-15 03:02 -0700 |
| Message-ID | <88031c87-796d-4435-823f-578abf511fe5@googlegroups.com> |
| In reply to | #89132 |
On Wednesday, June 15, 2016 at 7:45:52 AM UTC+1, Richard Heathfield wrote:
> On 15/06/16 07:16, Malcolm McLean wrote:
>
> I don't see why you think scope becomes more complicated when a function
> calls itself than when it calls some other function. The same rules
> apply in each case.
>
Normal structured programming
int high_level()
{
int variable = 42;
low_level(&variable);
return variable;
}
void low_level(int *ptr)
{
int variable = *ptr ? 1 : 0;
*ptr = variable;
}
recursive programming
int high_level(int *ptr)
{
int variable = *ptr;
low_level(&variable);
return variable;
}
void low_level(int *ptr)
{
int variable = *ptr ? (*ptr)--, high_level(ptr) : 0;
*ptr = variable;
}
much harder to work out which variables hold what and are active,
don't you agree? If only one copy on instance may be on the stack
at any one time, flow control is far easier to follow.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-15 11:39 +0100 |
| Message-ID | <njrb8n$bv6$1@dont-email.me> |
| In reply to | #89147 |
On 15/06/16 11:02, Malcolm McLean wrote:
> On Wednesday, June 15, 2016 at 7:45:52 AM UTC+1, Richard Heathfield wrote:
>> On 15/06/16 07:16, Malcolm McLean wrote:
>>
>> I don't see why you think scope becomes more complicated when a function
>> calls itself than when it calls some other function. The same rules
>> apply in each case.
>>
> Normal structured programming
>
> int high_level()
> {
> int variable = 42;
>
> low_level(&variable);
>
> return variable;
> }
>
> void low_level(int *ptr)
> {
> int variable = *ptr ? 1 : 0;
> *ptr = variable;
> }
Er, no. Normal structured programming:
int high_level(void)
{
return 1;
}
> recursive programming
>
> int high_level(int *ptr)
> {
> int variable = *ptr;
> low_level(&variable);
> return variable;
> }
>
> void low_level(int *ptr)
> {
> int variable = *ptr ? (*ptr)--, high_level(ptr) : 0;
> *ptr = variable;
> }
>
> much harder to work out which variables hold what and are active,
> don't you agree?
Sure, but only because you've chosen a silly example, where both the
techniques you show are too complicated for the task at hand.
There are some tasks for which recursion is a good fit, and you've
selected a task (returning 1) for which it's not a good fit (and neither
is your 'structured' example). So what?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-15 13:04 +0100 |
| Message-ID | <87inxay7xp.fsf@bsb.me.uk> |
| In reply to | #89130 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > [...] recursion makes programs harder to explain, understand, follow > and debug. All else being equal, my experience is that the reverse is often true (with the possible exception of debugging -- you may have a meaning in mind that makes that part true). Of course, all else is very rarely equal. C does not support recursion very well, and most C programmers are already wedded to the shuffling data between objects view of programming (as your recursive example later in the thread shows). Even so, *some* C programs are easier to explain, understand and follow when written recursively, so it can hardly be said to be a universal rule. > It's an exception to structured programming in many ways, including > that scope becomes more complicated. The scopes behave in exactly the same way when f calls g as when f calls g and then g calls f. Ironically, when programming with higher-order functions (functions that take and return functions) it is often possible to factor out the names altogether so the scopes actually get simpler because there aren't any arguments anymore (or there are, at least, fewer bound variables). And if your "in many ways" was anything but a rhetorical device, what are some of the other many ways in which it is an exception to structured programming? (It's a serious question -- I don't know very much about structured programming in any formal sense.) > However it's hard to do without > for some situations. I would guess that those cases where you grudgingly say it is hard to do without are actually cases where it makes for programs that are easier to explain, understand and follow. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-15 09:33 -0700 |
| Message-ID | <3c9dee3b-2fff-4b07-bf50-613a2d6746a7@googlegroups.com> |
| In reply to | #89158 |
On Wednesday, June 15, 2016 at 1:04:42 PM UTC+1, Ben Bacarisse wrote: > > And if your "in many ways" was anything but a rhetorical device, what > are some of the other many ways in which it is an exception to > structured programming? (It's a serious question -- I don't know very > much about structured programming in any formal sense.) > A structured program consists of a tree of subroutines (functions in C terminology), which is meant to be roughly balanced - you can't turn a list of commands into a structured program by drawing lines every so often and converting the step to a call, and you can't turn a list of commands into a structured program by saying that each command is actually a subroutine (which it often is in a lower level sense). it's got to be roughly balanced, non-degenerate tree. Each function has got to do something which makes sense from a human programmer's point of view. usually that means that the function is potentially re-usable. Even if in fact it is only called once, in a slightly different version of the program, it could be called from more than one place. Each subroutine has only one point of entry and one point of exit (C disguises the last requirement, but in fact most compilers enforce it at the machine level) and it always returns control to the point where it was called. It is allowed local variables, and globals are discouraged (I'd say ban, but then I draw a distinction between procedures and functions, and conventional ideas about structured programming do not). Subroutines have to be known. In C, this means you can pass a function pointer, but you must do so by name, as the function is called. You can't pass a function pointer whose identity is determined by some logic or other. So the structured program is potential call graph, whose properties we know at compile time. So what about recursion? It's clear that it violates some of these properties, though not in such a serious way that it destroys any notion of structured programming. The call graph is no longer likely to be a balanced tree. We can't determine maximum stack usage at compile time. We can't determine whether the program halts easily. (Most structured programs can be show to halt quite easily, though you can of course write a structured program which defeats this). It complicates the idea that "a function does something discrete", because we now have to specify if we are talking about one pass through the code or the entire call. It changes the graph. There is no longer a strict hierarchy of upper to lower. Then as Keith points out, it also complicates the notion of scope and a local variable. (Some C compilers disallow recursion because they don't have stacks. They pack all locals into a global memory space). > > > However it's hard to do without > > for some situations. > > I would guess that those cases where you grudgingly say it is hard to do > without are actually cases where it makes for programs that are easier > to explain, understand and follow. > Exactly. You can always eliminate recursion and use a data structure instead, but in the cases where recursion is the right solution, that tends to be a more complicated, less intuitive solution.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 11:35 -0700 |
| Message-ID | <lnbn32z4e4.fsf@kst-u.example.com> |
| In reply to | #89169 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Then as Keith points out, it also complicates the notion of scope and a local
> variable. (Some C compilers disallow recursion because they don't have
> stacks. They pack all locals into a global memory space).
[...]
Pedantically speaking, those aren't C compilers, since they fail
to implement a fundamental feature of the language.
Loosely speaking, it's perfectly reasonable to call them
"non-conforming C compilers" or "subset C compilers".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-15 21:27 +0100 |
| Message-ID | <87twguw62m.fsf@bsb.me.uk> |
| In reply to | #89169 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 15, 2016 at 1:04:42 PM UTC+1, Ben Bacarisse wrote: >> >> And if your "in many ways" was anything but a rhetorical device, what >> are some of the other many ways in which it is an exception to >> structured programming? (It's a serious question -- I don't know very >> much about structured programming in any formal sense.) >> > A structured program consists of a tree of subroutines (functions in C terminology), > which is meant to be roughly balanced - you can't turn a list of commands > into a structured program by drawing lines every so often and converting the > step to a call, and you can't turn a list of commands into a structured program > by saying that each command is actually a subroutine (which it often is in > a lower level sense). it's got to be roughly balanced, non-degenerate tree. > > Each function has got to do something which makes sense from a human > programmer's point of view. usually that means that the function is potentially > re-usable. Even if in fact it is only called once, in a slightly > different version of > the program, it could be called from more than one place. > > Each subroutine has only one point of entry and one point of exit (C disguises > the last requirement, but in fact most compilers enforce it at the machine level) > and it always returns control to the point where it was called. It is allowed > local variables, and globals are discouraged (I'd say ban, but then I draw a > distinction between procedures and functions, and conventional ideas about > structured programming do not). > > Subroutines have to be known. In C, this means you can pass a function pointer, > but you must do so by name, as the function is called. You can't pass a function > pointer whose identity is determined by some logic or other. > > So the structured program is potential call graph, whose properties we know > at compile time. I'm sorry but this is just silly. You've made up a bunch of stuff and called it structured programming. All of the most basic attributes of structured programs are missing from this description and you've pulled whole bunch of other criteria out of thin air. It's not all wrong (I can find two attributes of what I know as structured programming in all of this) but there nothing that can be reasonably discussed. > So what about recursion? > > It's clear that it violates some of these properties, though not in such a serious > way that it destroys any notion of structured programming. > > The call graph is no longer likely to be a balanced tree. > We can't determine maximum stack usage at compile time. > We can't determine whether the program halts easily. (Most structured > programs can be show to halt quite easily, though you can of course write > a structured program which defeats this). > It complicates the idea that "a function does something discrete", because > we now have to specify if we are talking about one pass through the code or > the entire call. > It changes the graph. There is no longer a strict hierarchy of upper > to lower. I started to address these points individually but I don't think there is much point. You've just made up some criteria and declared that recursive programs don't meet them. Showing where they do would be pointless since the initial criteria are just your own invention in the first place. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-15 13:41 -0700 |
| Message-ID | <82113d34-65ba-4243-93be-3bdf4e31bdab@googlegroups.com> |
| In reply to | #89200 |
On Wednesday, June 15, 2016 at 9:27:54 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > I'm sorry but this is just silly. You've made up a bunch of stuff and > called it structured programming. All of the most basic attributes of > structured programs are missing from this description and you've pulled > whole bunch of other criteria out of thin air. It's not all wrong (I > can find two attributes of what I know as structured programming in all > of this) but there nothing that can be reasonably discussed. > I wrote a description myself rather than cut and pasting it from elsewhere. If you want Google you know where to find it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-16 00:48 +0100 |
| Message-ID | <87oa72vwry.fsf@bsb.me.uk> |
| In reply to | #89204 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, June 15, 2016 at 9:27:54 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> I'm sorry but this is just silly. You've made up a bunch of stuff and >> called it structured programming. All of the most basic attributes of >> structured programs are missing from this description and you've pulled >> whole bunch of other criteria out of thin air. It's not all wrong (I >> can find two attributes of what I know as structured programming in all >> of this) but there nothing that can be reasonably discussed. >> > I wrote a description myself rather than cut and pasting it > from elsewhere. > If you want Google you know where to find it. Google was unable to help me find any evidence to support your claim that recursion is "an exception to structured programming in many ways". It confirmed that I have a reasonable understanding of both structured programming and of recursion, but not that the latter is in any way antithetical to the former. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 14:24 -0700 |
| Message-ID | <lnlh26xi10.fsf@kst-u.example.com> |
| In reply to | #89200 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On Wednesday, June 15, 2016 at 1:04:42 PM UTC+1, Ben Bacarisse wrote:
>>>
>>> And if your "in many ways" was anything but a rhetorical device, what
>>> are some of the other many ways in which it is an exception to
>>> structured programming? (It's a serious question -- I don't know very
>>> much about structured programming in any formal sense.)
>>>
>> A structured program consists of a tree of subroutines (functions in C terminology),
>> which is meant to be roughly balanced - you can't turn a list of commands
>> into a structured program by drawing lines every so often and converting the
>> step to a call, and you can't turn a list of commands into a structured program
>> by saying that each command is actually a subroutine (which it often is in
>> a lower level sense). it's got to be roughly balanced, non-degenerate tree.
>>
>> Each function has got to do something which makes sense from a human
>> programmer's point of view. usually that means that the function is potentially
>> re-usable. Even if in fact it is only called once, in a slightly
>> different version of
>> the program, it could be called from more than one place.
>>
>> Each subroutine has only one point of entry and one point of exit (C disguises
>> the last requirement, but in fact most compilers enforce it at the machine level)
>> and it always returns control to the point where it was called. It is allowed
>> local variables, and globals are discouraged (I'd say ban, but then I draw a
>> distinction between procedures and functions, and conventional ideas about
>> structured programming do not).
>>
>> Subroutines have to be known. In C, this means you can pass a function pointer,
>> but you must do so by name, as the function is called. You can't pass a function
>> pointer whose identity is determined by some logic or other.
>>
>> So the structured program is potential call graph, whose properties we know
>> at compile time.
>
> I'm sorry but this is just silly. You've made up a bunch of stuff and
> called it structured programming. All of the most basic attributes of
> structured programs are missing from this description and you've pulled
> whole bunch of other criteria out of thin air. It's not all wrong (I
> can find two attributes of what I know as structured programming in all
> of this) but there nothing that can be reasonably discussed.
On re-reading Malcolm's description, I see it says nothing about the
internals of a function except that it has one point of entry and one
point of exit. So a program in which each function is a tangled mass of
goto statements would be "structured" under Malcolm's definition.
If anyone wants to discuss "structured programming" as the term is
actually used, the Wikipedia article is probably a decent starting
point. https://en.wikipedia.org/wiki/Structured_programming
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-16 01:08 -0700 |
| Message-ID | <521cd673-dbc7-40e0-9725-3cae91ebb97a@googlegroups.com> |
| In reply to | #89211 |
On Wednesday, June 15, 2016 at 10:24:16 PM UTC+1, Keith Thompson wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > >> On Wednesday, June 15, 2016 at 1:04:42 PM UTC+1, Ben Bacarisse wrote: > >>> > >>> And if your "in many ways" was anything but a rhetorical device, what > >>> are some of the other many ways in which it is an exception to > >>> structured programming? (It's a serious question -- I don't know very > >>> much about structured programming in any formal sense.) > >>> > >> A structured program consists of a tree of subroutines (functions in C terminology), > >> which is meant to be roughly balanced - you can't turn a list of commands > >> into a structured program by drawing lines every so often and converting the > >> step to a call, and you can't turn a list of commands into a structured program > >> by saying that each command is actually a subroutine (which it often is in > >> a lower level sense). it's got to be roughly balanced, non-degenerate tree. > >> > >> Each function has got to do something which makes sense from a human > >> programmer's point of view. usually that means that the function is potentially > >> re-usable. Even if in fact it is only called once, in a slightly > >> different version of > >> the program, it could be called from more than one place. > >> > >> Each subroutine has only one point of entry and one point of exit (C disguises > >> the last requirement, but in fact most compilers enforce it at the machine level) > >> and it always returns control to the point where it was called. It is allowed > >> local variables, and globals are discouraged (I'd say ban, but then I draw a > >> distinction between procedures and functions, and conventional ideas about > >> structured programming do not). > >> > >> Subroutines have to be known. In C, this means you can pass a function pointer, > >> but you must do so by name, as the function is called. You can't pass a function > >> pointer whose identity is determined by some logic or other. > >> > >> So the structured program is potential call graph, whose properties we know > >> at compile time. > > > > I'm sorry but this is just silly. You've made up a bunch of stuff and > > called it structured programming. All of the most basic attributes of > > structured programs are missing from this description and you've pulled > > whole bunch of other criteria out of thin air. It's not all wrong (I > > can find two attributes of what I know as structured programming in all > > of this) but there nothing that can be reasonably discussed. > > On re-reading Malcolm's description, I see it says nothing about the > internals of a function except that it has one point of entry and one > point of exit. So a program in which each function is a tangled mass of > goto statements would be "structured" under Malcolm's definition. > Yes it would. Except the functions are meant to be quite short, the "balanced tree" requirement. So the functions can only be a small tangled mess. I was talking mainly about structured programming and recursion, however. The Wiki article is mostly about the historical development of the idea and whilst it's worth reading, it doesn't give you a good sense of what is "structured programming" versus other paradigms.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-16 08:52 -0700 |
| Message-ID | <lnmvmlw2p0.fsf@kst-u.example.com> |
| In reply to | #89256 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, June 15, 2016 at 10:24:16 PM UTC+1, Keith Thompson wrote:
[...]
>> On re-reading Malcolm's description, I see it says nothing about the
>> internals of a function except that it has one point of entry and one
>> point of exit. So a program in which each function is a tangled mass of
>> goto statements would be "structured" under Malcolm's definition.
>>
> Yes it would.
> Except the functions are meant to be quite short, the "balanced tree"
> requirement. So the functions can only be a small tangled mess.
>
> I was talking mainly about structured programming and recursion,
> however. The Wiki article is mostly about the historical development
> of the idea and whilst it's worth reading, it doesn't give you
> a good sense of what is "structured programming" versus other
> paradigms.
So once again, you take an existing term with an accepted meaning
and apply your own inconsistent meaning to it. Presumably your
usage is Right and everyone else's is Wrong.
Code in which functions (however small) consist of tangled messes
of gotos does not qualify as "structured programming". (Knuth has
argued that limited use of gotos is consistent with structured
programming, but we're specifically talking about a "tangled mess
of goto statements".)
Let's call it "Malcolm-structured-programming", and the rest of us
can ignore it and move on.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-16 09:06 -0700 |
| Message-ID | <5b886f4c-b935-4a0f-a66c-82615e9cd443@googlegroups.com> |
| In reply to | #89291 |
On Thursday, June 16, 2016 at 4:53:05 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > So once again, you take an existing term with an accepted meaning > and apply your own inconsistent meaning to it. Presumably your > usage is Right and everyone else's is Wrong. > > Code in which functions (however small) consist of tangled messes > of gotos does not qualify as "structured programming". (Knuth has > argued that limited use of gotos is consistent with structured > programming, but we're specifically talking about a "tangled mess > of goto statements".) > > Let's call it "Malcolm-structured-programming", and the rest of us > can ignore it and move on. > That main structuring element in almost every type of structure programming is the subroutine. That's not how the concept started. But it is how it has developed. You can however has a structured program that contains no subroutines and consists entirely of blocks. I suggest that using the term with that meaning, today, would be far more confusing. But you still have the basic idea of a tree with code returning to the point of evocation after the block terminates. Now if we say that "functions are nodes, and shall be sufficiently small for a human programmer to inspect and check for correctness without automatic tools" then it follows that essentially we can forget about function internals. As long as the function has one point of entry, one point of exit, and does what it says, we're basically fine. However we can also talk about the function internals. It's detail rather than overview. And whilst historically the ban on goto was important, it isn't any longer very important. A function can be goto spaghetti, but it's only a small plate of spaghetti. I'm certainly not saying function internals aren't important, but they're not part of the overview.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 10:12 +0200 |
| Message-ID | <nk0be0$glf$1@dont-email.me> |
| In reply to | #89295 |
On 16/06/16 18:06, Malcolm McLean wrote: > On Thursday, June 16, 2016 at 4:53:05 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> So once again, you take an existing term with an accepted meaning >> and apply your own inconsistent meaning to it. Presumably your >> usage is Right and everyone else's is Wrong. >> >> Code in which functions (however small) consist of tangled messes >> of gotos does not qualify as "structured programming". (Knuth has >> argued that limited use of gotos is consistent with structured >> programming, but we're specifically talking about a "tangled mess >> of goto statements".) >> >> Let's call it "Malcolm-structured-programming", and the rest of us >> can ignore it and move on. >> > That main structuring element in almost every type of structure programming > is the subroutine. > That's not how the concept started. But it is how it has developed. > > You can however has a structured program that contains no subroutines > and consists entirely of blocks. I suggest that using the term with that > meaning, today, would be far more confusing. But you still have the basic > idea of a tree with code returning to the point of evocation after the > block terminates. > > Now if we say that "functions are nodes, and shall be sufficiently small for > a human programmer to inspect and check for correctness without automatic > tools" then it follows that essentially we can forget about function internals. > As long as the function has one point of entry, one point of exit, and does > what it says, we're basically fine. > > However we can also talk about the function internals. It's detail rather than > overview. And whilst historically the ban on goto was important, it isn't any > longer very important. A function can be goto spaghetti, but it's only a small > plate of spaghetti. I'm certainly not saying function internals aren't important, > but they're not part of the overview. > Malcolm, "structured programming" means "the program code has a structure that can be seen and understood". Subroutines, or "functions" as they are known in C, are often part of that - but not necessarily. Blocks are almost always part of the structure. In most circumstances, while or for loops are more structured than loops made from gotos. Functions don't have to have a single point of entry and exit in order to be part of structured programming. Coroutines are a structure component that have multiple entry and exit points, as are iterators. There are no size limitations, no requirements for "balance", no limitations on recursion. If you can understand the structure of the code, and understand the control flow, it is structured programming. If you can't figure out where and why code jumps here and there, it is unstructured.
[toc] | [prev] | [next] | [standalone]
Page 3 of 19 — ← Prev page 1 2 [3] 4 5 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web