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 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-17 10:47 +0100 |
| Message-ID | <nk0gut$20q$1@dont-email.me> |
| In reply to | #89377 |
On 17/06/16 10:13, Malcolm McLean wrote: > On Friday, June 17, 2016 at 9:20:31 AM UTC+1, David Brown wrote: <snip> >> The clue is in the name - it is a "call graph", not a "call tree". In a >> "graph", there can be more than one node leading into a given node, not >> just one. >> > > I wrote: > > 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. > > I did not use the term call graph. > Other people said "that's a call graph, and Malcolm has it wrong". > Now someone can use the wrong or a non-standard word for something, > or he can use the right word but describe the entity incorrectly. > > But he can't do both. If he says "that's a zibra", you may not say "no, you're > wrong, it's a "zebra". And you're wrong again. A zebra has black and white > stripes, that one has pink stripes". Yes, your logic is fine. It's your premise that's screwed. There ain't no such thing as no 'zibra'. Structured programming is far less formal a term than you would have us believe. The best way to think of it is simply this: don't let the flow control jump around all over the place, or you'll get a headache. The impact that this idea has on my programming is: 1) I don't use goto; 2) I don't use setjmp/longjmp; 3) I tend to avoid try/throw/catch in C++; 4) I don't muck about with function pointers as a /substitute/ for goto (I first came across that on site in the early 1990s, and it was horrific to behold); 5) I (almost always) observe a single entry and a single exit for loops and functions. (By 'almost always' I mean that, if I break this rule (which hardly ever happens), I tend to think 'ooh, that's a bit dodgy', and I may well change my mind and do it the 'proper' way after all.) But those are /my/ structured programming rules. David may well have slightly different rules, and Ben may have others still. Whatever those rules might be, I suspect that most clc subscribers have /some/ kind of self-imposed discipline on the way that we write code, in order to make it more manageable. And, whatever that discipline is, we can reasonably call it structured programming. -- 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-17 03:41 -0700 |
| Message-ID | <c8baae5f-dec6-423f-a0cb-8cf6630861e9@googlegroups.com> |
| In reply to | #89381 |
On Friday, June 17, 2016 at 10:47:16 AM UTC+1, Richard Heathfield wrote: > On 17/06/16 10:13, Malcolm McLean wrote: > > On Friday, June 17, 2016 at 9:20:31 AM UTC+1, David Brown wrote: > <snip> > >> The clue is in the name - it is a "call graph", not a "call tree". In a > >> "graph", there can be more than one node leading into a given node, not > >> just one. > >> > > > > I wrote: > > > > 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. > > > > I did not use the term call graph. > > Other people said "that's a call graph, and Malcolm has it wrong". > > Now someone can use the wrong or a non-standard word for something, > > or he can use the right word but describe the entity incorrectly. > > > > But he can't do both. If he says "that's a zibra", you may not say "no, you're > > wrong, it's a "zebra". And you're wrong again. A zebra has black and white > > stripes, that one has pink stripes". > > > Yes, your logic is fine. It's your premise that's screwed. There ain't > no such thing as no 'zibra'. > How do you know? it's very unlikely that horses with pink stripes exist. But neither do unicorns, and we can talk about unicorns. There is substantial agreement about what they are and what one would look like. Maybe zibras are mentioned in a fantasy work which I have read but you haven't. > > Structured programming is far less formal a term than you would have us > believe. The best way to think of it is simply this: don't let the flow > control jump around all over the place, or you'll get a headache. > The term is used in that sense. But really that isn't what it means. it's not a synonym for 'well-written code". > > The impact that this idea has on my programming is: > > 1) I don't use goto; > 2) I don't use setjmp/longjmp; > 3) I tend to avoid try/throw/catch in C++; > 4) I don't muck about with function pointers as a /substitute/ for goto > (I first came across that on site in the early 1990s, and it was > horrific to behold); > 5) I (almost always) observe a single entry and a single exit for loops > and functions. (By 'almost always' I mean that, if I break this rule > (which hardly ever happens), I tend to think 'ooh, that's a bit dodgy', > and I may well change my mind and do it the 'proper' way after all.) > > But those are /my/ structured programming rules. David may well have > slightly different rules, and Ben may have others still. Whatever those > rules might be, I suspect that most clc subscribers have /some/ kind of > self-imposed discipline on the way that we write code, in order to make > it more manageable. And, whatever that discipline is, we can reasonably > call it structured programming. > You can. But then you need another term for what I am describing. Now my plan is to tighten up the rules and christen it "bit-based programming". But I'm not talking about my own extensions to Djikstra's ideas here, but what is already in place. You could use the term "procedural decomposition", but as far as I'm aware, the normal term is "structured programming".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-06-17 11:49 +0100 |
| Message-ID | <nk0kk5$e2f$1@dont-email.me> |
| In reply to | #89387 |
On 17/06/16 11:41, Malcolm McLean wrote: > On Friday, June 17, 2016 at 10:47:16 AM UTC+1, Richard Heathfield wrote: >> On 17/06/16 10:13, Malcolm McLean wrote: >>> On Friday, June 17, 2016 at 9:20:31 AM UTC+1, David Brown wrote: >> <snip> >>>> The clue is in the name - it is a "call graph", not a "call tree". In a >>>> "graph", there can be more than one node leading into a given node, not >>>> just one. >>>> >>> >>> I wrote: >>> >>> 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. >>> >>> I did not use the term call graph. >>> Other people said "that's a call graph, and Malcolm has it wrong". >>> Now someone can use the wrong or a non-standard word for something, >>> or he can use the right word but describe the entity incorrectly. >>> >>> But he can't do both. If he says "that's a zibra", you may not say "no, you're >>> wrong, it's a "zebra". And you're wrong again. A zebra has black and white >>> stripes, that one has pink stripes". >> >> >> Yes, your logic is fine. It's your premise that's screwed. There ain't >> no such thing as no 'zibra'. >> > How do you know? I looked in my zibra closet, and it was empty. > it's very unlikely that horses with pink stripes exist. I conducted an image search, and I found a few close calls. :-) > But neither do unicorns, > and we can talk about unicorns. There is substantial agreement about > what they are and what one would look like. Maybe zibras are mentioned > in a fantasy work which I have read but you haven't. No, they're not. I looked in /your/ zibra closet. >> Structured programming is far less formal a term than you would have us >> believe. The best way to think of it is simply this: don't let the flow >> control jump around all over the place, or you'll get a headache. >> > The term is used in that sense. But really that isn't what it means. Yes, it /is/ what it means, because it is used in that sense. You might seek to use it to mean something else, and that's fine, but until such time as that meaning is also adopted by other people, it's just a Malcolmism. > it's not a synonym for 'well-written code". No, but well-written code does tend to be structured (and has other qualities, too, which is why they're not synonyms). >> >> The impact that this idea has on my programming is: >> >> 1) I don't use goto; >> 2) I don't use setjmp/longjmp; >> 3) I tend to avoid try/throw/catch in C++; >> 4) I don't muck about with function pointers as a /substitute/ for goto >> (I first came across that on site in the early 1990s, and it was >> horrific to behold); >> 5) I (almost always) observe a single entry and a single exit for loops >> and functions. (By 'almost always' I mean that, if I break this rule >> (which hardly ever happens), I tend to think 'ooh, that's a bit dodgy', >> and I may well change my mind and do it the 'proper' way after all.) >> >> But those are /my/ structured programming rules. David may well have >> slightly different rules, and Ben may have others still. Whatever those >> rules might be, I suspect that most clc subscribers have /some/ kind of >> self-imposed discipline on the way that we write code, in order to make >> it more manageable. And, whatever that discipline is, we can reasonably >> call it structured programming. >> > You can. > > But then you need another term for what I am describing. Right. And that's your problem right there. > Now my plan is to tighten up the rules and christen it "bit-based programming". > But I'm not talking about my own extensions to Djikstra's ideas here, but > what is already in place. You could use the term "procedural decomposition", > but as far as I'm aware, the normal term is "structured programming". No, you need another term. Note, too, that "functional decomposition" (to which "procedural composition" is comfortably close) is already taken. -- 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-06-18 10:52 +0000 |
| Message-ID | <57652671.4227343@news.xs4all.nl> |
| In reply to | #89387 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Friday, June 17, 2016 at 10:47:16 AM UTC+1, Richard Heathfield wrote: > > On 17/06/16 10:13, Malcolm McLean wrote: > > > But he can't do both. If he says "that's a zibra", you may not say "no, you're > > > wrong, it's a "zebra". And you're wrong again. A zebra has black and white > > > stripes, that one has pink stripes". > > > > Yes, your logic is fine. It's your premise that's screwed. There ain't > > no such thing as no 'zibra'. > > How do you know? > it's very unlikely that horses with pink stripes exist. But neither do unicorns, > and we can talk about unicorns. There is substantial agreement about > what they are and what one would look like. Maybe zibras are mentioned > in a fantasy work which I have read but you haven't. "Fantasy" being the operant word, here. Whole hordes of people have made plans for "when" the zombie apocalypse happens. Predictably, most of those plans are misguided, self-aggrandising, and in fact quite boring to contemplate. Some, though, are well-planned, and as realistic as a fantasy discussion can be. Those are far in the minority, but they do exist - reputedly, FEMA has one, though AIUI they only use it to meta-test their scenario handing. Good, bad, boring, all fantasy: yes, you _can_ talk about the zombie apocalypse. And yes, you can differ in opinion about what "would" happen. One thing all professionals agree on, though: if you ever find someone who believes the zombie apocalypse will _actually_ occur, you're dealing with a complete crackpot who does not have the right to call anyone an "insolent schoolboy". Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 13:18 +0200 |
| Message-ID | <nk0maf$j8f$1@dont-email.me> |
| In reply to | #89381 |
On 17/06/16 11:47, Richard Heathfield wrote: > Yes, your logic is fine. It's your premise that's screwed. There ain't > no such thing as no 'zibra'. Someone once claimed there was no such thing as a Gruffalo, and look how well /that/ turned out!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-06-14 23:59 +0100 |
| Message-ID | <87ziqnxtpp.fsf@bsb.me.uk> |
| In reply to | #89073 |
BartC <bc@freeuk.com> writes: > 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. Your complaint was about something C allows. Your explanation was about named owners. Your example of why this matters was in your private language. If the issue is universal, you need to explain why the fact that C's inner blocks are not named matters as far as the contained declarations are concerned. > If it wanted to as an extension, then the existing > proliferation of anonymous names with no path to them from anywhere > else makes it hard. > > That makes such names a bad idea. No, because you can do exactly what your private language does in the almost but not quite C you are thinking of. You could either limit the references to those names that fit your pattern or you could extend C with the restriction you like. But I find this argument preposterous. Feature X in C is bad because is makes turning C into the language I want harder carries no weight for me. The merits or otherwise of feature X in C should be about how it helps or hinders programming (expressiveness, comprehension, clarity, maintenance and so on), not about how it helps or hinders making C into some other language. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-15 10:20 +0200 |
| Message-ID | <njr34n$g6n$1@dont-email.me> |
| In reply to | #89071 |
On 14/06/16 16:21, BartC wrote:
> 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):
>
> int main (void) {
> printf("%d", fn.size);
> }
>
> void fn(void) {
> const size = 100; // named constant
> }
>
> This would print 100. It is possible to access names (consts, static
> variables, types, enums) inside functions from outside (whether the
> function is active or not. If the function is in module M, then it's
> M.fn.size.
>
> The point is being able to have a fully qualified path to any named
> resource in a program is useful (putting aside matters of controlling
> external access to such resources). It might just make it a bit easier
> in a debugger to specify a particular instance of a variable.
>
I simply cannot understand why you are so keen on this feature. If I
put a variable inside the scope of a function (or block within a
function), it is because I don't want to access it from the outside. If
I have an identifier that I want to be able to access from several
functions, I declare it outside those functions, at file scope (and with
"static" as appropriate).
The idea that any function, anywhere, can access data or identifiers
within other functions, is just inconceivably bad in my view. It is a
return to spaghetti programming and unstructured Basic, and you lose all
control over what code accesses what data and at what time. In
addition, you are not merely tying your compiler's hands with respect to
optimisation - you are chopping off its arms and legs.
The C model of block scoping is simple and clear, and is not
particularly difficult to implement (certainly it is not one of the
major challenges when making a compiler). It works very well in
practice, and programmers like it - many programming languages follow
the same model. It is arguable that there could be some advantages in
making some tweaks (for example, allowing identifiers declared within
the same file to see each other without regard to ordering or needing
forward declarations), but that would be a small point.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-15 10:30 +0100 |
| Message-ID | <njr777$tjj$1@dont-email.me> |
| In reply to | #89142 |
On 15/06/2016 09:20, David Brown wrote:
> On 14/06/16 16:21, BartC wrote:
>> Actually this is pretty much what happens in the languages I implement.
>> To illustrate in C syntax (but it won't work in C):
>>
>> int main (void) {
>> printf("%d", fn.size);
>> }
>>
>> void fn(void) {
>> const size = 100; // named constant
>> }
>>
>> This would print 100.
>> The point is being able to have a fully qualified path to any named
>> resource in a program is useful (putting aside matters of controlling
>> external access to such resources).
> I simply cannot understand why you are so keen on this feature.
The feature came about by accident. It just illustrates the
possibilities of having a unique 'dotted path' for every named entity in
a program.
> The idea that any function, anywhere, can access data or identifiers
> within other functions, is just inconceivably bad in my view.
People are always going on about refactoring functions into smaller
ones. So function F now also has child functions A, B and C. But without
nested functions, if A, B and C need access to a type T defined in F, T
now has to be taken outside, exposing it to other functions and possibly
clashing with more global Ts (or the identically named Ts of other
similar Fs that also need refactoring).
The feature I mentioned allows A, B and C to simply use F.T.
> It is a
> return to spaghetti programming and unstructured Basic, and you lose all
> control over what code accesses what data and at what time.
But it's OK to be able to do exactly the same with Classes?
(Those have access control, but there's nothing to stop you having
everything public. Note that access to a function's internal names is
prohibited for auto frame variables; it's only for static entities, just
like accessing the members of a class using C.name.)
> The C model of block scoping is simple and clear,
It's not so bad to grasp, although it would be clearer if all scopes
ranged from the start of the current {,} block and not part-way along.
> and is not
> particularly difficult to implement (certainly it is not one of the
> major challenges when making a compiler).
Implementing it presents some extra difficulties IMO, such as resolving
names in an expression: rather than just look at a small number of scope
levels in a symbol table, you might have to scan a potentially larger
number of scope blocks within the code-tree.
> It works very well in
> practice, and programmers like it - many programming languages follow
> the same model.
(So do mine, with one difference: while declarations can appear anywhere
just like in C, the rules for scope are different: scope is always
function-wide).
It is arguable that there could be some advantages in
> making some tweaks (for example, allowing identifiers declared within
> the same file to see each other without regard to ordering or needing
> forward declarations), but that would be a small point.
(And that's exactly how my scheme works by default. You can have all
declarations within a function at the end of a function if you want**!
A bit like the glossary in certain books being either at the end, at the
beginning, or sometimes described in footnotes throughout the book.
**Except for declarations that affect parsing, such as user-type names.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-15 12:55 +0200 |
| Message-ID | <njrc6p$fcj$1@dont-email.me> |
| In reply to | #89146 |
On 15/06/16 11:30, BartC wrote:
> On 15/06/2016 09:20, David Brown wrote:
>> On 14/06/16 16:21, BartC wrote:
>
>>> Actually this is pretty much what happens in the languages I implement.
>>> To illustrate in C syntax (but it won't work in C):
>>>
>>> int main (void) {
>>> printf("%d", fn.size);
>>> }
>>>
>>> void fn(void) {
>>> const size = 100; // named constant
>>> }
>>>
>>> This would print 100.
>
>>> The point is being able to have a fully qualified path to any named
>>> resource in a program is useful (putting aside matters of controlling
>>> external access to such resources).
>
>> I simply cannot understand why you are so keen on this feature.
>
> The feature came about by accident. It just illustrates the
> possibilities of having a unique 'dotted path' for every named entity in
> a program.
My question is why you might think this is such an important or useful
feature, not how it came about. You argue vehemently that this is so
important and useful that the C scope model is inferior or broken - but
have not said what you think is so great about this idea.
>
>> The idea that any function, anywhere, can access data or identifiers
>> within other functions, is just inconceivably bad in my view.
>
> People are always going on about refactoring functions into smaller
> ones. So function F now also has child functions A, B and C. But without
> nested functions, if A, B and C need access to a type T defined in F, T
> now has to be taken outside, exposing it to other functions and possibly
> clashing with more global Ts (or the identically named Ts of other
> similar Fs that also need refactoring).
Yes, that it is true - if you break things into functions but need
access to shared identifiers, then in C those shared identifiers need to
be at a larger (typically file level) scope. With C, the only way to
limit /that/ scope is to break up the code into smaller files.
But the solution to this problem is not a free-for-all, where every
function has access to everything in every other function (albeit using
dotted paths for resolution). The solution is to have more flexibility
for scopes, and more levels. For example, you could allow nested
functions - many languages do that (including a gcc extension to C).
C++ provides more scopes with classes and namespaces, each of which can
be nested, as well as local functions (lambdas).
C has taken the attitude that nested scopes within functions, together
with file level scopes, are good enough. They are perhaps not perfect
or structured enough for all desired uses, but they are clear and simple.
>
> The feature I mentioned allows A, B and C to simply use F.T.
>
>> It is a
>> return to spaghetti programming and unstructured Basic, and you lose all
>> control over what code accesses what data and at what time.
>
> But it's OK to be able to do exactly the same with Classes?
Classes provide a controlled scope, which says exactly what can access
the different names in different situations. It is not the same thing
at all - it is, in fact, completely different because it is controlled.
>
> (Those have access control, but there's nothing to stop you having
> everything public. Note that access to a function's internal names is
> prohibited for auto frame variables; it's only for static entities, just
> like accessing the members of a class using C.name.)
>
>> The C model of block scoping is simple and clear,
>
> It's not so bad to grasp, although it would be clearer if all scopes
> ranged from the start of the current {,} block and not part-way along.
It is perfectly clear that identifiers scope starts when the identifier
is defined, rather than at some earlier part in the code.
>
>> and is not
>> particularly difficult to implement (certainly it is not one of the
>> major challenges when making a compiler).
>
> Implementing it presents some extra difficulties IMO, such as resolving
> names in an expression: rather than just look at a small number of scope
> levels in a symbol table, you might have to scan a potentially larger
> number of scope blocks within the code-tree.
You just step backwards up the tree - it is /not/ hard.
>
>> It works very well in
>> practice, and programmers like it - many programming languages follow
>> the same model.
>
> (So do mine, with one difference: while declarations can appear anywhere
> just like in C, the rules for scope are different: scope is always
> function-wide).
>
> It is arguable that there could be some advantages in
>> making some tweaks (for example, allowing identifiers declared within
>> the same file to see each other without regard to ordering or needing
>> forward declarations), but that would be a small point.
>
> (And that's exactly how my scheme works by default. You can have all
> declarations within a function at the end of a function if you want**!
I said it is arguable - not that I thought it was a good idea. I am
quite happy that scope does not start until the definition or
declaration of an identifier. I think it would be okay if that were
relaxed at file scope (and namespace scope in C++), but I would not want
it inside a function at block scope. I don't want it to be valid to use
a variable before it is defined. (A key separation here is that at file
scope or C++ namespace scope, you have functions, and your variables
have program lifetimes - inside a function your variables are mostly of
transient lifetime and the scope matches the lifetime.)
>
> A bit like the glossary in certain books being either at the end, at the
> beginning, or sometimes described in footnotes throughout the book.
>
> **Except for declarations that affect parsing, such as user-type names.)
>
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-15 12:39 +0100 |
| Message-ID | <njreq9$oki$1@dont-email.me> |
| In reply to | #89153 |
On 15/06/2016 11:55, David Brown wrote:
> On 15/06/16 11:30, BartC wrote:
>> It's not so bad to grasp, although it would be clearer if all scopes
>> ranged from the start of the current {,} block and not part-way along.
>
> It is perfectly clear that identifiers scope starts when the identifier
> is defined, rather than at some earlier part in the code.
In that case it's not clear why it should end at the next } (matching
the previous {). Its scope is not aligned with the start of this block,
so why should it be with the end?
Probably, if that was fixed (the scope extends retroactively to the
start of the block**) then it wouldn't be a big deal, and the vast
majority of code would still work.
I suspect it's done that way by some accident, by which time it was too
late to fix and every new compiler had to work the same way. Then, given
the fact that it was here to stay, everyone feels obliged to laud the
feature and dissmiss any suggestions that it might have been better done
differently.
Outside functions, C has only one scope, file-scope. But imagine there
were two: header scope, and file-scope. Applying the same logic as
happens within blocks, you can have a situation where function addint()
is an external (header-scope) name until half-way through the file,
until a local addint() is defined, which now overrides the external version?
Sounds crazy, yes? In that case ....
(It might cause problems for certain one-pass compilers, but why should
be concerned about such compilers in the 21st century?
And also, with that rule in place, then in this situation:
{ a=0;
int a;
....
since the first a must refer to the one subsequently declared, the
declaration ought to be moved near the start anyway.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-15 14:11 +0200 |
| Message-ID | <njrgks$vkn$1@dont-email.me> |
| In reply to | #89157 |
On 15/06/16 13:39, BartC wrote:
> On 15/06/2016 11:55, David Brown wrote:
>> On 15/06/16 11:30, BartC wrote:
>
>>> It's not so bad to grasp, although it would be clearer if all scopes
>>> ranged from the start of the current {,} block and not part-way along.
>>
>> It is perfectly clear that identifiers scope starts when the identifier
>> is defined, rather than at some earlier part in the code.
>
> In that case it's not clear why it should end at the next } (matching
> the previous {). Its scope is not aligned with the start of this block,
> so why should it be with the end?
It is clear in the sense that it is clearly defined in the way that C
works - in the same way that it is clear that {} are used to delimit
blocks in C, even though it is different in some other programming
languages.
As to /why/ it is this way in C, it is pretty reasonable that you cannot
use an identifier before it is defined. And it is pretty reasonable
that in a structured language, the scope of that identifier is limited
in some way - the end of the current block is a good choice.
This is not the only way to pick rules for scoping, but it is a
straightforward and easily understood method, and it works well for both
compiler implementers and compiler users.
>
> Probably, if that was fixed (the scope extends retroactively to the
> start of the block**) then it wouldn't be a big deal, and the vast
> majority of code would still work.
I don't think it would break any code - but it would make it easier to
write incorrect code, and it would mean that when you want to find the
definition of a variable you have to search over a wider area (forwards
and backwards) rather than just backwards.
>
> I suspect it's done that way by some accident, by which time it was too
> late to fix and every new compiler had to work the same way. Then, given
> the fact that it was here to stay, everyone feels obliged to laud the
> feature and dissmiss any suggestions that it might have been better done
> differently.
I suspect you are completely wrong, and it is an active decision.
It is conceivable that the decision was based on what the early C folks
thought would be easiest for compilers to implement, rather than a
better choice for programming. But if that had been the case, and if it
really were the case that making the scope stretch back to the start of
the block was such a good idea, then there would have been nothing to
stop it being added in later C standards. After all, C99 added
significant new freedom in mixing declarations and statements - it could
have been added there. And like the C99 addition, it would not have
broken existing code.
>
> Outside functions, C has only one scope, file-scope. But imagine there
> were two: header scope, and file-scope. Applying the same logic as
> happens within blocks, you can have a situation where function addint()
> is an external (header-scope) name until half-way through the file,
> until a local addint() is defined, which now overrides the external
> version?
>
> Sounds crazy, yes? In that case ....
It sounds crazy, because that is simply not how headers work in C - it
is purely a textual inclusion feature, so there is no distinction
between a header and the rest of the file.
Now, if you want to suggest C should have some sort of "module" feature
or a separation between interfaces and implementations, then that's
fine. It is highly unlikely to happen in C - but hopefully it will
appear in C++ before too long (it looks like it won't make it for C++17,
but maybe the next version).
>
> (It might cause problems for certain one-pass compilers, but why should
> be concerned about such compilers in the 21st century?
>
> And also, with that rule in place, then in this situation:
>
> { a=0;
> int a;
> ....
>
> since the first a must refer to the one subsequently declared, the
> declaration ought to be moved near the start anyway.)
>
That sounds like you are saying that you don't want the scope of "int a"
to extend back to the beginning of the block - you want the scoping
rules to match those of C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 09:44 -0700 |
| Message-ID | <lnwplqz9ji.fsf@kst-u.example.com> |
| In reply to | #89160 |
David Brown <david.brown@hesbynett.no> writes:
> On 15/06/16 13:39, BartC wrote:
[...]
>> Probably, if that was fixed (the scope extends retroactively to the
>> start of the block**) then it wouldn't be a big deal, and the vast
>> majority of code would still work.
>
> I don't think it would break any code - but it would make it easier to
> write incorrect code, and it would mean that when you want to find the
> definition of a variable you have to search over a wider area (forwards
> and backwards) rather than just backwards.
It would break existing code. Worse, it would take existing valid code
and change its meaning. There probably isn't a lot of code that would
be affected, but there's undoubtedly some. It would be possible for a
tool to detect affected code in the mindbogglingly unlikely event that
such a change were made in a future C standard.
{
int n = 10;
{
n = 20;
int n;
}
}
In C, the assignment `n = 20;` refers to the `n` defined in the outer
scope. With BartC's desired change, it would refer to the `n` defined
in the inner scope.
This kind of shadowing, as I've mentioned before, is not necessarily a
good idea, but it's supported by the language.
>> I suspect it's done that way by some accident, by which time it was too
>> late to fix and every new compiler had to work the same way. Then, given
>> the fact that it was here to stay, everyone feels obliged to laud the
>> feature and dissmiss any suggestions that it might have been better done
>> differently.
>
> I suspect you are completely wrong, and it is an active decision.
It makes compilers simpler, since names (other than labels) always refer
to something that's already been declared. It's also simpler for human
readers, who don't have to scan both forward and backward to find the
declaration.
And it avoids any need for special-case rules to handle things like
int x = y;
int y = x;
I can't think of any advantage at all in extending the scope of a
declaration to the beginning of the containing block. (Of course
BartC is free to do anything he likes with his own private language.)
[...]
--
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-15 18:38 +0100 |
| Message-ID | <njs3qt$bak$1@dont-email.me> |
| In reply to | #89170 |
On 15/06/2016 17:44, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 15/06/16 13:39, BartC wrote:
> [...]
>>> Probably, if that was fixed (the scope extends retroactively to the
>>> start of the block**) then it wouldn't be a big deal, and the vast
>>> majority of code would still work.
>>
>> I don't think it would break any code - but it would make it easier to
>> write incorrect code, and it would mean that when you want to find the
>> definition of a variable you have to search over a wider area (forwards
>> and backwards) rather than just backwards.
>
> It would break existing code. Worse, it would take existing valid code
> and change its meaning. There probably isn't a lot of code that would
> be affected, but there's undoubtedly some. It would be possible for a
> tool to detect affected code in the mindbogglingly unlikely event that
> such a change were made in a future C standard.
>
> {
> int n = 10;
> {
> n = 20;
> int n;
> }
> }
>
> In C, the assignment `n = 20;` refers to the `n` defined in the outer
> scope. With BartC's desired change, it would refer to the `n` defined
> in the inner scope.
Yes, but if the intention is to declare things at their first use
(rather than allow declarations out of order), then the above would be
changed to:
{
int n = 20;
}
It means code like your example would not be allowed, or would be ambiguous.
> It makes compilers simpler, since names (other than labels) always refer
> to something that's already been declared.
My suggestion doesn't change that. It would remove a possible source of
error, if someone were to mistakenly insert a reference to n before its
declaration; it wouldn't unexpectedly match a more global version.
(Having two versions of a name in scope /in the same block/ is anyway
bad form in my opinion, as I believe I might have mentioned.)
> I can't think of any advantage at all in extending the scope of a
> declaration to the beginning of the containing block.
Well, I've given you a few to be getting on with. (Note that this still
keeps block scopes and multiple instances of the same identifier within
a function.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 11:46 -0700 |
| Message-ID | <ln7fdqz3wq.fsf@kst-u.example.com> |
| In reply to | #89176 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 17:44, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 15/06/16 13:39, BartC wrote:
>> [...]
>>>> Probably, if that was fixed (the scope extends retroactively to the
>>>> start of the block**) then it wouldn't be a big deal, and the vast
>>>> majority of code would still work.
>>>
>>> I don't think it would break any code - but it would make it easier to
>>> write incorrect code, and it would mean that when you want to find the
>>> definition of a variable you have to search over a wider area (forwards
>>> and backwards) rather than just backwards.
>>
>> It would break existing code. Worse, it would take existing valid code
>> and change its meaning. There probably isn't a lot of code that would
>> be affected, but there's undoubtedly some. It would be possible for a
>> tool to detect affected code in the mindbogglingly unlikely event that
>> such a change were made in a future C standard.
>>
>> {
>> int n = 10;
>> {
>> n = 20;
>> int n;
>> }
>> }
>>
>> In C, the assignment `n = 20;` refers to the `n` defined in the outer
>> scope. With BartC's desired change, it would refer to the `n` defined
>> in the inner scope.
>
> Yes, but if the intention is to declare things at their first use
> (rather than allow declarations out of order), then the above would be
> changed to:
>
> {
> int n = 20;
> }
Changed? Changed by what? I'm talking about the effect of that code,
which a compiler can either accept or reject -- not the effect of some
other code.
> It means code like your example would not be allowed, or would be ambiguous.
Making it ambiguous is a terribly bad idea.
I really don't know what you're proposing. If the scope of the
inner n includes the entire block containing its declaration,
how would the above code be illegal?
Under your proposal, would this be legal (assuming no outer declaration
of n)?
{
n = 20;
int n;
}
Can you clearly explain just what you're proposing?
>> It makes compilers simpler, since names (other than labels) always refer
>> to something that's already been declared.
>
> My suggestion doesn't change that. It would remove a possible source of
> error, if someone were to mistakenly insert a reference to n before its
> declaration; it wouldn't unexpectedly match a more global version.
So what would it refer to?
> (Having two versions of a name in scope /in the same block/ is anyway
> bad form in my opinion, as I believe I might have mentioned.)
And as I believe I've also mentioned several times. But I'm mainly
talking about what would be *allowed*.
>> I can't think of any advantage at all in extending the scope of a
>> declaration to the beginning of the containing block.
>
> Well, I've given you a few to be getting on with. (Note that this still
> keeps block scopes and multiple instances of the same identifier within
> a function.)
--
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-15 20:07 +0100 |
| Message-ID | <njs91t$vl6$1@dont-email.me> |
| In reply to | #89184 |
On 15/06/2016 19:46, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 15/06/2016 17:44, Keith Thompson wrote:
>>> {
>>> int n = 10;
>>> {
>>> n = 20;
>>> int n;
>>> }
>>> }
>>>
>>> In C, the assignment `n = 20;` refers to the `n` defined in the outer
>>> scope. With BartC's desired change, it would refer to the `n` defined
>>> in the inner scope.
>>
>> Yes, but if the intention is to declare things at their first use
>> (rather than allow declarations out of order), then the above would be
>> changed to:
>>
>> {
>> int n = 20;
>> }
>
> Changed? Changed by what?
Think about it: if only one unique name was could be in scope during the
lifetime of a block, then your example would work, but the n=20 refers
to the second n.
You might get the language to allow that (out-of-order declarations),
but a better idea is to declare names before use. (And I thought most of
the point of mixed declarations was to declare names at their first use
anyway.)
Then the code would need to be changed (by the programmer). It would
much clearer which n is being referred to (as there is no prior
reference to n in the block), and it would keep the compiler 'simple' by
having all names declared before use (other than labels; functions we
can argue about some other time).
Win-win all round.
> Under your proposal, would this be legal (assuming no outer declaration
> of n)?
>
> {
> n = 20;
> int n;
> }
As I said, it could be, but it's better for the reasons I listed that
the declaration was moved. (This code could generate an error or warning.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 12:23 -0700 |
| Message-ID | <lny466xnle.fsf@kst-u.example.com> |
| In reply to | #89187 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 19:46, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 15/06/2016 17:44, Keith Thompson wrote:
>>>> {
>>>> int n = 10;
>>>> {
>>>> n = 20;
>>>> int n;
>>>> }
>>>> }
>>>>
>>>> In C, the assignment `n = 20;` refers to the `n` defined in the outer
>>>> scope. With BartC's desired change, it would refer to the `n` defined
>>>> in the inner scope.
>>>
>>> Yes, but if the intention is to declare things at their first use
>>> (rather than allow declarations out of order), then the above would be
>>> changed to:
>>>
>>> {
>>> int n = 20;
>>> }
>>
>> Changed? Changed by what?
>
> Think about it: if only one unique name was could be in scope during the
> lifetime of a block, then your example would work, but the n=20 refers
> to the second n.
Is my thinking about it supposed to magically tell me what you mean?
It doesn't.
I agree that the code at the top of this message is poor style. I'm
*not* asking how you would rearrange it to make it better. I'm asking
how a compiler should handle it.
> You might get the language to allow that (out-of-order declarations),
> but a better idea is to declare names before use. (And I thought most of
> the point of mixed declarations was to declare names at their first use
> anyway.)
Yes, declaring names before use (as C already requires) is great.
In C, the scope of a declaration inside a block extends from the
declaration itself to the end of the enclosing block. You've proposed
that the scope should extend from the beginning of the block (before the
declaration) to the end of the block.
> Then the code would need to be changed (by the programmer). It would
> much clearer which n is being referred to (as there is no prior
> reference to n in the block), and it would keep the compiler 'simple' by
> having all names declared before use (other than labels; functions we
> can argue about some other time).
>
> Win-win all round.
So were you *not* proposing expanding the scope of declarations to cover
the entire block? Or are you now saying that's a bad idea?
Here's what you wrote upthread:
On 15/06/16 13:39, BartC wrote:
> On 15/06/2016 11:55, David Brown wrote:
>> On 15/06/16 11:30, BartC wrote:
>>> It's not so bad to grasp, although it would be clearer if all
>>> scopes ranged from the start of the current {,} block and not
>>> part-way along.
>>
>> It is perfectly clear that identifiers scope starts when the
>> identifier is defined, rather than at some earlier part in the
>> code.
>
> In that case it's not clear why it should end at the next }
> (matching the previous {). Its scope is not aligned with the start
> of this block, so why should it be with the end?
[...]
> Probably, if that was fixed (the scope extends retroactively to
> the start of the block**) then it wouldn't be a big deal, and the
> vast majority of code would still work.
>> Under your proposal, would this be legal (assuming no outer declaration
>> of n)?
>>
>> {
>> n = 20;
>> int n;
>> }
>
> As I said, it could be, but it's better for the reasons I listed that
> the declaration was moved. (This code could generate an error or warning.)
Given your proposal from upthread, that would be perfectly valid, since
the scope of n would extend from the start of the block to the end of
the block.
If it generates an error, then presumably it's because the scope of n
does *not* start at the beginning of the block.
The only thing I can think of is that you're using the word "scope" with
some different meaning than the usual one.
--
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-15 20:43 +0100 |
| Message-ID | <njsb4u$7j9$1@dont-email.me> |
| In reply to | #89193 |
On 15/06/2016 20:23, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 15/06/2016 19:46, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>>> On 15/06/2016 17:44, Keith Thompson wrote:
>>>>> {
>>>>> int n = 10;
>>>>> {
>>>>> n = 20;
>>>>> int n;
>>>>> }
>>>>> }
>>>>>
>>>>> In C, the assignment `n = 20;` refers to the `n` defined in the outer
>>>>> scope. With BartC's desired change, it would refer to the `n` defined
>>>>> in the inner scope.
>>>>
>>>> Yes, but if the intention is to declare things at their first use
>>>> (rather than allow declarations out of order), then the above would be
>>>> changed to:
>>>>
>>>> {
>>>> int n = 20;
>>>> }
>>>
>>> Changed? Changed by what?
>>
>> Think about it: if only one unique name was could be in scope during the
>> lifetime of a block, then your example would work, but the n=20 refers
>> to the second n.
>
> Is my thinking about it supposed to magically tell me what you mean?
> It doesn't.
>
> I agree that the code at the top of this message is poor style. I'm
> *not* asking how you would rearrange it to make it better. I'm asking
> how a compiler should handle it.
>
>> You might get the language to allow that (out-of-order declarations),
>> but a better idea is to declare names before use. (And I thought most of
>> the point of mixed declarations was to declare names at their first use
>> anyway.)
>
> Yes, declaring names before use (as C already requires) is great.
>
> In C, the scope of a declaration inside a block extends from the
> declaration itself to the end of the enclosing block. You've proposed
> that the scope should extend from the beginning of the block (before the
> declaration) to the end of the block.
Yes, so the scope of that second 'int n' covers the whole of that block.
With that 'int n' somewhere at the top level of this block, no 'n' names
in outer scopes are accessible.
The block is associated with at most ONE instance of any identifier, in
this case, just one 'n' variable.
... What more can I say about it, and how many times can I repeat it?
The only other big thing to clear up is what to do about references to
'n' in the block that occur before the declaration of 'int n' in that
same block. There are a few possibilities:
* Make those illegal
* Allow them, thus allowing out-of-order declarations (but giving
different behaviour to how C works now which can cause confusion)
* Use supercat's proposal to block visibility to outer n's, and only
allow the inner n to be used after its declaration (like my first point
I think)
But there are also some desirable aims:
* You want to declare names at their first use, which is the attraction
of mixed declarations. So if a prior reference to a name is made, you
really want to move the declaration to that point (I've said this a few
times)
* You want to declare names before any references to them, to match what
happens with other parts of C, and which, I've been told, makes
compilers simpler.
* You don't want a prior declaration of a name to cause confusion
because the behaviour currently is different when that happens.
Put it all together, and you end up with:
{
int n=20;
}
which is where we'd got to an hour ago.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 13:38 -0700 |
| Message-ID | <lnporixk5g.fsf@kst-u.example.com> |
| In reply to | #89196 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 20:23, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 15/06/2016 19:46, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>> On 15/06/2016 17:44, Keith Thompson wrote:
>>>>>> {
>>>>>> int n = 10;
>>>>>> {
>>>>>> n = 20;
>>>>>> int n;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> In C, the assignment `n = 20;` refers to the `n` defined in the outer
>>>>>> scope. With BartC's desired change, it would refer to the `n` defined
>>>>>> in the inner scope.
>>>>>
>>>>> Yes, but if the intention is to declare things at their first use
>>>>> (rather than allow declarations out of order), then the above would be
>>>>> changed to:
>>>>>
>>>>> {
>>>>> int n = 20;
>>>>> }
>>>>
>>>> Changed? Changed by what?
>>>
>>> Think about it: if only one unique name was could be in scope during the
>>> lifetime of a block, then your example would work, but the n=20 refers
>>> to the second n.
>>
>> Is my thinking about it supposed to magically tell me what you mean?
>> It doesn't.
>>
>> I agree that the code at the top of this message is poor style. I'm
>> *not* asking how you would rearrange it to make it better. I'm asking
>> how a compiler should handle it.
>>
>>> You might get the language to allow that (out-of-order declarations),
>>> but a better idea is to declare names before use. (And I thought most of
>>> the point of mixed declarations was to declare names at their first use
>>> anyway.)
>>
>> Yes, declaring names before use (as C already requires) is great.
>>
>> In C, the scope of a declaration inside a block extends from the
>> declaration itself to the end of the enclosing block. You've proposed
>> that the scope should extend from the beginning of the block (before the
>> declaration) to the end of the block.
>
> Yes, so the scope of that second 'int n' covers the whole of that block.
>
> With that 'int n' somewhere at the top level of this block, no 'n' names
> in outer scopes are accessible.
>
> The block is associated with at most ONE instance of any identifier, in
> this case, just one 'n' variable.
>
> ... What more can I say about it, and how many times can I repeat it?
So given (and throughout this I will assume that there are no other
declarations of the identifier "n"):
{
/* BEFORE */
int n;
/* AFTER */
}
In C, BEFORE is outside the scope of n, and AFTER is inside the scope of
n.
You propose a change that would cause both BEFORE and AFTER to be within
the scope of n. The scope of n begins at the opening "{", not at its
declaration.
Is that right so far?
Now suppose I replace the BEFORE comment as follows:
{
n = 20;
int n;
/* AFTER */
}
With your proposed change, the assignment `n = 20;` is within the scope
of n. And if expanding the scope of declarations is the only change you
make to C, then that assignment is perfectly legal. The identifier "n"
is in scope, which means it's visible, which means we can refer to it.
And yet you say that that assignment is either illegal or ambiguous.
> The only other big thing to clear up is what to do about references to
> 'n' in the block that occur before the declaration of 'int n' in that
> same block.
No, if the only change you make to the language is to expand the scope
of identifiers declared within a block, there's nothing else to clear
up.
If you want to add some *restrictions* on top of that change, you can do
so, but any added restrictions do not obviously follow from the idea of
expanding scope.
> There are a few possibilities:
>
> * Make those illegal
Then in what sense is the scope expanded? If you expand the scope of
"n" to cover the entire block, but make references to "n" before its
declaration illegal, how does that differ from C as it's currently
defined? I suggest it doesn't.
> * Allow them, thus allowing out-of-order declarations (but giving
> different behaviour to how C works now which can cause confusion)
Yes, that could break existing code.
> * Use supercat's proposal to block visibility to outer n's, and only
> allow the inner n to be used after its declaration (like my first point
> I think)
That's an interesting idea. It could break some existing code, and
compilers can already warn about shadowed declarations, so I don't think
it's necessary. (gcc's -Wshadow doesn't seem to be enabled by -Wall or
-Wextra; perhaps it should be.)
> But there are also some desirable aims:
>
> * You want to declare names at their first use, which is the attraction
> of mixed declarations. So if a prior reference to a name is made, you
> really want to move the declaration to that point (I've said this a few
> times)
This requires no changes to the language.
> * You want to declare names before any references to them, to match what
> happens with other parts of C, and which, I've been told, makes
> compilers simpler.
This requires no changes to the language.
> * You don't want a prior declaration of a name to cause confusion
> because the behaviour currently is different when that happens.
>
> Put it all together, and you end up with:
>
> {
> int n=20;
> }
>
> which is where we'd got to an hour ago.
Which is perfectly legal C, and does not require any changes to the
language.
As far as I can tell, everything you've said so far adds up to
essentially nothing. What am I missing?
--
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-15 21:59 +0100 |
| Message-ID | <njsfk4$o0e$1@dont-email.me> |
| In reply to | #89203 |
On 15/06/2016 21:38, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> ... What more can I say about it, and how many times can I repeat it?
>
> So given (and throughout this I will assume that there are no other
> declarations of the identifier "n"):
>
> {
> /* BEFORE */
> int n;
> /* AFTER */
> }
>
> In C, BEFORE is outside the scope of n, and AFTER is inside the scope of
> n.
>
> You propose a change that would cause both BEFORE and AFTER to be within
> the scope of n. The scope of n begins at the opening "{", not at its
> declaration.
>
> Is that right so far?
Yes.
> As far as I can tell, everything you've said so far adds up to
> essentially nothing. What am I missing?
Take:
{int A;
{ P;
Q;
A=10;
R;
int A;
S;
T;
}
Currently the scopes of A and A are as follows:
{int A; // outer A
{ P; // outer A
Q; // outer A
A=10; // outer A
R; // outer A
int A; // inner A
S; // inner A
T; // inner A
} // outer A
Under the proposal, this changes to:
{int A; // outer A
{ P; // inner A
Q; // inner A
A=10; // inner A (but may need reordering...
R; // inner A
int A; // inner A
S; // inner A
T; // inner A
} // outer A
... if necessary or desirable to declare names before use/at first use.)
As can now be clearly seen, the outer A is ousted from the inner block
as it contains its own definition of A. The inner block is only
associated with one A, not two which needs a cross-over somewhere along
the block.
This seems perfectly clear and advantageous; I don't know how I can
explain it further unless someone else wants to have a go.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 14:42 -0700 |
| Message-ID | <lnh9cuxh6x.fsf@kst-u.example.com> |
| In reply to | #89205 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 21:38, Keith Thompson wrote:
[...]
>> As far as I can tell, everything you've said so far adds up to
>> essentially nothing. What am I missing?
>
> Take:
>
> {int A;
> { P;
> Q;
> A=10;
> R;
> int A;
> S;
> T;
> }
>
> Currently the scopes of A and A are as follows:
>
> {int A; // outer A
> { P; // outer A
> Q; // outer A
> A=10; // outer A
> R; // outer A
> int A; // inner A
> S; // inner A
> T; // inner A
> } // outer A
>
> Under the proposal, this changes to:
>
> {int A; // outer A
> { P; // inner A
> Q; // inner A
> A=10; // inner A (but may need reordering...
> R; // inner A
> int A; // inner A
> S; // inner A
> T; // inner A
> } // outer A
>
> ... if necessary or desirable to declare names before use/at first use.)
>
> As can now be clearly seen, the outer A is ousted from the inner block
> as it contains its own definition of A.
I'd say "hidden" rather than "ousted".
> The inner block is only
> associated with one A, not two which needs a cross-over somewhere along
> the block.
>
> This seems perfectly clear and advantageous; I don't know how I can
> explain it further unless someone else wants to have a go.
Your latest description is clear. The problem is that you've clearly
said other things that clear contradict this latest description.
Again, you're saying that the scope of a declaration in side a block
would extend, not from the declaration to the end of the block as it
does in C, but from the beginning of the block to the end of the block.
That's fine. I dislike it, but it's clearly and unambiguously
expressed.
(Since you seem to agree that declarations *should* precede usage,
it seems that the only purpose of your proposed change is to change
the handling of shadowed identifiers. Avoiding shadowed identifiers
is IMHO a much easier way to do that.)
**BUT**
Upthread, when I asked:
Under your proposal, would this be legal (assuming no outer
declaration of n)?
{
n = 20;
int n;
}
you replied:
As I said, it could be, but it's better for the reasons I listed
that the declaration was moved. (This code could generate an error
or warning.)
Under your most recent description, that 4-line chunk of code would be
perfectly legal, and the "n" in the assignment would refer to the object
"n" defined on the next line.
Let's ignore for now the question of whether it would be good style, and
of whether a compiler might generate a warning for it.
(This code could generate an error or warning.)
What did you mean by that? How could it generate an error if it's
legal?
I assert (a) that it cannot generate a compile-time error unless it's
illegal, and (b) if it's illegal, it's because the assignment is not
within the scope of "n". And if you want it to be illegal, then C
already does that perfectly well. (Again, I'm assuming there is no
outer declaration of "n" in this case.)
Or was that statement just a mistake?
--
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]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web