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 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-06-16 16:56 -0700 |
| Message-ID | <b26147b2-16ef-4f95-949d-31748aa41e3d@googlegroups.com> |
| In reply to | #89346 |
On Thursday, June 16, 2016 at 5:45:11 PM UTC-5, Bart wrote:
> On 16/06/2016 23:26, Ike Naar wrote:
> > On 2016-06-16, BartC <bc@freeuk.com> wrote:
> >> On 16/06/2016 16:32, Ike Naar wrote:
>
> >>> One can write a similar example with function-wide scopes:
> >>>
> >>> int *foo(void)
> >>> {
> >>> int A = 77;
> >>> return &A;
> >>> }
> >>>
> >>> void bar(void)
> >>> {
> >>> int *p = foo();
> >>> printf("*p=%d\n", *p);
> >>> }
> >>>
> >>> Same subtle bug.
> >>
> >> That one's not quite as subtle. It's more obvious that an auto-variable
> >> in a function will no longer exist on exit from the function.
> >
> > An auto-variable in a block ceases to exist on exit from the block.
> > An auto-variable in a function ceases to exist on exit from the
> > function. Why would one behaviour be more obvious than the other?
>
> It just is.
>
> People declare things without regard for whereabouts they are in
> relation to a block. Or blocks are added or removed later that will
> quietly change the scope of a name, or a whole block is moved somewhere
> else in the function.
What people? Tell those people to stop doing that.
--
whew. problem solved.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-06-18 12:03 +0100 |
| Message-ID | <87r3buvjx6.fsf@gmail.com> |
| In reply to | #89346 |
BartC <bc@freeuk.com> writes: >> An auto-variable in a block ceases to exist on exit from the block. >> An auto-variable in a function ceases to exist on exit from the >> function. Why would one behaviour be more obvious than the other? > > It just is. Solid stuff.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-18 13:43 +0100 |
| Message-ID | <nk3flu$i44$1@dont-email.me> |
| In reply to | #89520 |
On 18/06/2016 12:03, Gareth Owen wrote: > BartC <bc@freeuk.com> writes: > >>> An auto-variable in a block ceases to exist on exit from the block. >>> An auto-variable in a function ceases to exist on exit from the >>> function. Why would one behaviour be more obvious than the other? >> >> It just is. > > Solid stuff. Perhaps you haven't followed the thread. I gave an example of getting block scope wrong which with most compilers was not diagnosed yet gave the expected results. The equivalent error with function scope(**) was more likely to be diagnosed and more likely to give the wrong results. /That's/ why one is more obvious than another. People here are assuming that automatons not humans are doing the programming. Or maybe they are, themselves, perfect programmers who never get anything wrong. And, since that has now come up, function scope is a more universal concept across languages than block scope is. For that reason also, the subtleties of block scope can be less obvious. (Further, if code implementing algorithms can be made more portable across languages if block-scope dependencies are avoided.) (** With it's obvious English meaning. That is, a lexical scope which spans an entire function. It's not hard!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-16 16:35 -0700 |
| Message-ID | <lnlh24vh9w.fsf@kst-u.example.com> |
| In reply to | #89345 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2016-06-16, BartC <bc@freeuk.com> wrote:
[...]
>> That one's not quite as subtle. It's more obvious that an auto-variable
>> in a function will no longer exist on exit from the function.
>
> An auto-variable in a block ceases to exist on exit from the block.
> An auto-variable in a function ceases to exist on exit from the
> function. Why would one behaviour be more obvious than the other?
In fact there's only one relevant rule: An auto variable in a block
ceases to exist on exit from the block. It doesn't matter whether
it's the top level block of a function definition or not.
(It might sometimes make a difference in the generated code.
For example, all the automatic storage for a function invocation
might be allocated on entry and deallocated on return. But an
auto object logically ceases to exist at the end of its lifetime,
whether its memory has been deallocated or not.)
--
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 | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-16 20:57 -0400 |
| Message-ID | <njvhtn$hmh$1@dont-email.me> |
| In reply to | #89345 |
On 6/16/2016 7:50 PM, Stefan Ram wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> An auto-variable in a block ceases to exist on exit from the block.
>
> The might be true,
True the is.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-06-16 21:12 -0400 |
| Message-ID | <njviqe$k81$1@dont-email.me> |
| In reply to | #89345 |
On 06/16/2016 07:50 PM, Stefan Ram wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> An auto-variable in a block ceases to exist on exit from the block.
>
> The might be true, when one is adding all the additional
> unspoken assumptions, but otherwise:
Here's the precise rule, with all relevant assumptions explicitly stated:
"An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration, ..."
(6.2.4p5)
"For such an object that does not have a variable length array type, its
lifetime extends from entry into the block with which it is associated
until execution of that block ends in any way. (Entering an enclosed
block or calling a function suspends, but does not end, execution of the
current block.) If the block is entered recursively, a new instance of
the object is created each time." (6.2.4p6)
> #include <stdio.h>
>
> int main( void )
> { static int depth = -1; ++depth;
>
> int blockvariable = 0;
>
> if( depth < 1 )main();
>
> if( depth == 0 )printf
> ( "'exit from block.' was printed,\n"
> "and the block then indeed was exited.\n"
> "But here I am, printing legally the auto\n"
> "variable 'blockvariable' from this very\n"
> "block that was exited:\n"
> "%d\n", blockvariable );
>
> if( depth == 1 &&( --depth, 1 ))puts
> ( "exit from block.\n" ); }
>
> exit from block.
>
> 'exit from block.' was printed,
> and the block then indeed was exited.
> But here I am, printing legally the auto
> variable 'blockvariable' from this very
> block that was exited:
> 0
>
There's a separate instance of blockvariable associated with each
recursive call main() that occurs during the execution of that program.
Each such instance of blockvariable ceases to exist when the
corresponding block exits. The corresponding block is the outermost
block of that instance of main(). Every occurrence of the printf()
statement prints the value of the blockvariable associated with the
instance of main() that printf() is called from. That blockvariable has
not ceased to exist yet, and is therefore not a counter-example to the
principle stated above.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-16 22:31 -0400 |
| Message-ID | <njvnev$ufn$1@dont-email.me> |
| In reply to | #89354 |
On 6/16/2016 9:58 PM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> "For such an object that does not have a variable length array type, its
>> lifetime extends from entry into the block with which it is associated
>> until execution of that block ends in any way. (Entering an enclosed
>> block or calling a function suspends, but does not end, execution of the
>> current block.) If the block is entered recursively, a new instance of
>> the object is created each time." (6.2.4p6)
>
> I believe even this wording from the standard could be
> written in a clearer way. I already posted a suggestion
> in my previous post (which needs to be modified at the place
> with the »declarator«; it needs to use »start of the block«).
if (rand() < 999) goto label;
{ // "start" of block
char *x = "world";
printf("Hello, %s!\n", x);
label:
x = "Columbus"; // `x' exists, either way
printf("Goodbye, %x!\n", x);
}
In this example, `x' exists even if entry to the block skips right
past the "start" without ever encountering it.
The Standard's wording on this point is perfectly clear to me,
despite the difficulties some others appear to have with it.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-16 22:32 -0400 |
| Message-ID | <njvnh6$ufn$2@dont-email.me> |
| In reply to | #89357 |
On 6/16/2016 10:31 PM, Eric Sosman wrote:
>
> if (rand() < 999) goto label;
> { // "start" of block
> char *x = "world";
> printf("Hello, %s!\n", x);
> label:
> x = "Columbus"; // `x' exists, either way
> printf("Goodbye, %x!\n", x);
s/%x/%s/. (Sigh.)
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-06-16 19:59 -0700 |
| Message-ID | <cb71924b-7b01-4227-a2a9-b7d75dd86420@googlegroups.com> |
| In reply to | #89357 |
On Friday, June 17, 2016 at 3:32:07 AM UTC+1, Eric Sosman wrote:
> On 6/16/2016 9:58 PM, Stefan Ram wrote:
> > James Kuyper <jameskuyper@verizon.net> writes:
> >> "For such an object that does not have a variable length array type, its
> >> lifetime extends from entry into the block with which it is associated
> >> until execution of that block ends in any way. (Entering an enclosed
> >> block or calling a function suspends, but does not end, execution of the
> >> current block.) If the block is entered recursively, a new instance of
> >> the object is created each time." (6.2.4p6)
> >
> > I believe even this wording from the standard could be
> > written in a clearer way. I already posted a suggestion
> > in my previous post (which needs to be modified at the place
> > with the »declarator«; it needs to use »start of the block«).
>
> if (rand() < 999) goto label;
> { // "start" of block
> char *x = "world";
> printf("Hello, %s!\n", x);
> label:
> x = "Columbus"; // `x' exists, either way
> printf("Goodbye, %x!\n", x);
> }
>
> In this example, `x' exists even if entry to the block skips right
> past the "start" without ever encountering it.
>
> The Standard's wording on this point is perfectly clear to me,
> despite the difficulties some others appear to have with it.
>
Yes, that's awful.
If you're going to jump into blocks, they shouldn't contain
locals.
In structured programming, (the other thread topic) blocks have
one point of entry and one point of exit, so the problem doesn't
arise. Unfortunately it's too restrictive to make C blocks
structured programming blocks.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-17 03:11 -0700 |
| Message-ID | <052745e2-4c95-417b-aa39-1f5f400b6583@googlegroups.com> |
| In reply to | #89357 |
On Thursday, June 16, 2016 at 9:32:07 PM UTC-5, Eric Sosman wrote:
> if (rand() < 999) goto label;
> { // "start" of block
> char *x = "world";
> printf("Hello, %s!\n", x);
> label:
> x = "Columbus"; // `x' exists, either way
> printf("Goodbye, %x!\n", x);
> }
What about something like:
int main(void)
{
unsigned char x,y,z;
unsigned char *px=&x,*py=&y,*pz=&z;
int pass=0;
{
TWO:
*px='x', *py='y', *pz='z';
x='1'; y='2'; z='3';
unsigned char x='X',y;
goto THREE;
if (!pass) goto ONE;
unsigned char z;
THREE:
printf("%d %d %d", x,y,z);
return 0;
ONE:
x='a'; y='b'; z='c';
px=&x; py=&y; pz=&z;
pass=1;
goto TWO;
}
}
From what I can tell, the effect of the declarations located before THREE
is to create storage which exists in the preceding portion of the block,
but is not accessible by name until the parts of the code which follow
it. When code reaches ONE, the value of the inner x is 'X' while y and
z are Indeterminate. When x reaches TWO, the inner x, y, and z hold
'a', 'b', and 'c' respectively. At THREE, x and y continue to hold their
values but z will have become Indeterminate again (note that since z is
an unsigned char whose address is taken, reading it is not UB.
Does that all seem right? Can you think of any reason why passing through
the declaration of z should cause it to lose its value but skipping over
should let x and y keep theirs?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-06-17 09:11 -0400 |
| Message-ID | <nk0su3$ber$1@dont-email.me> |
| In reply to | #89354 |
On 06/16/2016 09:58 PM, Stefan Ram wrote: > James Kuyper <jameskuyper@verizon.net> writes: >> "For such an object that does not have a variable length array type, its >> lifetime extends from entry into the block with which it is associated >> until execution of that block ends in any way. (Entering an enclosed >> block or calling a function suspends, but does not end, execution of the >> current block.) If the block is entered recursively, a new instance of >> the object is created each time." (6.2.4p6) > > I believe even this wording from the standard could be > written in a clearer way. I already posted a suggestion > in my previous post (which needs to be modified at the place > with the �declarator�; it needs to use �start of the block�). > > The problem is that �the block� is a region of the /source > code/, i. e., it is static. So the first sentence does not > exclude the interpretation that exiting a recursively nested > incarnation of the block ends the lifetime of an object from > an outer incarnation or that the lifetime of an object related > to a recursively nested incarnation of the block only ends > when the outermost block is exited, because otherwise the > �execution of the block� has not yet �ended�. The second > sentence with �recursively� cannot repair all of this. > > You all might be reading those wordings through the > correction lenses of someone who already knows what they > struggle to express; I try to read the words more as they > are written. I think you've got a point here - the standard defines a block in a way that makes it a source-code construct, whereas these rules are clearly (and I emphasize "clearly") written on the assumption that the blocks it refers to are run-time features that can have multiple distinct instances existing simultaneously if a function is called recursively. I don't think there's anything unclear about this wording, there's just a conflict between the definition of the term "block" and the way they're using that term in these clauses. If they defined a "block instance" appropriately, and re-wrote the above text in terms of block instances, rather than blocks, I don't think any other modification would be required.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-15 12:20 -0700 |
| Message-ID | <d540117d-f9f9-459d-8bc7-c44ce6ec9d66@googlegroups.com> |
| In reply to | #89184 |
On Wednesday, June 15, 2016 at 1:46:21 PM UTC-5, Keith Thompson wrote:
> 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?
I can't speak to Bart's intention in particular, but one approach that
some languages use is to say that outer-scope identifiers become buried
at the start of any scope where they are redeclared, but the inner-scope
identifiers don't become available until after their point of declaration.
A single-pass compiler could enforce that by having each use of an
identifier which isn't found in inner scope search outer scopes and, if
the identifier is found there, creating an alias in local scope (which
would then block any subsequent attempted redefinition). Note that
creating such aliases would offer advantages beyond the ability to make
inner-scope variables shadow outer-scope variables at the start of the
block where they're declared:
1. An outer-scope variable which is used once is likely to be used again,
and searching for it in small local symbol table may be faster than
searching in a presumably-larger global symbol table.
2. Having variables participate in register optimization may require that
they have more complicated data structures associated with them than
would be necessary otherwise. If global variables can only participate
in register optimizations within a function, there's no need to hold
such data structures for all the global variables that aren't used
within the current function. Creating entries in the local symbol
table to hold such variables would allow the supplemental information
to be attached to them.
While some compilers may enforce the indicated rule by making multiple
passes through the code, parse tree, or other such data structures, it
would also be possible to enforce it in a single-pass compiler using the
approach above.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 12:40 -0700 |
| Message-ID | <lntwguxmtu.fsf@kst-u.example.com> |
| In reply to | #89192 |
supercat@casperkitty.com writes:
> On Wednesday, June 15, 2016 at 1:46:21 PM UTC-5, Keith Thompson wrote:
>> 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?
>
> I can't speak to Bart's intention in particular, but one approach that
> some languages use is to say that outer-scope identifiers become buried
> at the start of any scope where they are redeclared, but the inner-scope
> identifiers don't become available until after their point of declaration.
That's not unreasonable, but if that's what Bart meant he could have
said so.
Note that gcc's "-wshadow" option warns about declarations with the same
name in nested scopes (regardless of references as in the above example).
[...]
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 09:24 -0700 |
| Message-ID | <ln1t3y1ktn.fsf@kst-u.example.com> |
| In reply to | #89146 |
BartC <bc@freeuk.com> writes:
[...]
> (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.)
Why do type names affect parsing?
In C, typedef names affect parsing because the typedef feature
was added to the language relatively late in its evolution.
In non-typedef C, it's always possible to recognize a type name
syntactically, since type names consist of sequences of keywords
and symbols ((), [], *). (An identifier that's an enumeration
constant can appear in a type name, but only between [].) A typedef
effectively creates a new context-sensitive keyword, requiring the
parser to refer to the symbol table to recognize it.
In a new language with a carefully designed syntax, it should be
possible to recognize type names syntactically, even type names
that are single identifiers.
I suppose it's not a big problem (for C it's a mild annoyance,
not a fatal flaw), but it's something to consider when designing
a new 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:16 +0100 |
| Message-ID | <njs2ht$6i9$1@dont-email.me> |
| In reply to | #89168 |
On 15/06/2016 17:24, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> (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.) > > Why do type names affect parsing? > > In C, typedef names affect parsing because the typedef feature > was added to the language relatively late in its evolution. > In non-typedef C, it's always possible to recognize a type name > syntactically, since type names consist of sequences of keywords > and symbols ((), [], *). (An identifier that's an enumeration > constant can appear in a type name, but only between [].) A typedef > effectively creates a new context-sensitive keyword, requiring the > parser to refer to the symbol table to recognize it. > > In a new language with a carefully designed syntax, it should be > possible to recognize type names syntactically, even type names > that are single identifiers. That's quite hard even with special syntax. The most foolproof way is to use a keyword to introduce a type specifier: declare A B; A is a type, B is a variable name. Otherwise you're looking at: A B; Here, you might be able to say that two adjacent identifiers can only occur if the first is a type-name. But this sounds a bit fragile. (And type names could be dotted sequences depending on language: A.B.C D) When seeing a set of function parameters such as (A,B,C,D), are these all types with no parameter names, or all parameter names with no type? How about casts: the C-style (A)(B) could be casting B to type A, or it can be calling function A with parameter B. Or both could be casts. It's not impossible, but having types declared ahead of use makes many things easier and the language design more flexible. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-15 11:15 -0700 |
| Message-ID | <cea729df-7617-4b1b-8293-389bd47c5f8b@googlegroups.com> |
| In reply to | #89175 |
On Wednesday, June 15, 2016 at 12:16:53 PM UTC-5, Bart wrote: > On 15/06/2016 17:24, Keith Thompson wrote: > > In a new language with a carefully designed syntax, it should be > > possible to recognize type names syntactically, even type names > > that are single identifiers. > > That's quite hard even with special syntax. Not really. Pascal compilers on the PC and Macintosh would accept: Var Foo: Array[0..1931] of ^Array[0..7] of Woozle; (the leading caret means "pointer to"). One would access an element of Foo with syntax like "Foo[123]^[6].fnord". The syntax is a little more verbose than C, but doesn't need parentheses. The most popular compiler on the PC would also allow variables which were initialized with compile- time constants via: Const Foo: Array[0..2] of Integer = (1,2,3); The use of "Const" for that purpose may seem a bit strange, given that the variables were writable, but in versions 2 and 3 of Turbo Pascal for the PC such variables lived in the code segment rather than the data segment, which meant that code could have up to 64K of non-initialized variables plus another 64K for code and initialized variables (combined) plus whatever was left over as heap storage. In any case, having a keyword to designate variable declarations and a separator between the new name and the type would allow building a syntax tree even without a symbol table.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-15 20:09 +0100 |
| Message-ID | <njs95o$f1$1@dont-email.me> |
| In reply to | #89178 |
On 15/06/2016 19:15, supercat@casperkitty.com wrote: > On Wednesday, June 15, 2016 at 12:16:53 PM UTC-5, Bart wrote: >> On 15/06/2016 17:24, Keith Thompson wrote: >>> In a new language with a carefully designed syntax, it should be >>> possible to recognize type names syntactically, even type names >>> that are single identifiers. >> >> That's quite hard even with special syntax. ... > In any case, having a keyword to designate variable declarations and a > separator between the new name and the type would allow building a syntax > tree even without a symbol table. Yes, with a keyword it's easy, except that people want to be able to type: int a,b,c; or: T a,b,c; without needing a special keyword for the latter. By 'special syntax' I meant restricting it so that two adjacent identifiers match fewer possibilities in the syntax, so that the likelihood is that A B is a declaration. But as I went on to say, that might not solve all parsing ambiguities. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 11:32 -0700 |
| Message-ID | <lnfusez4j8.fsf@kst-u.example.com> |
| In reply to | #89175 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 17:24, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> (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.)
>>
>> Why do type names affect parsing?
>>
>> In C, typedef names affect parsing because the typedef feature
>> was added to the language relatively late in its evolution.
>> In non-typedef C, it's always possible to recognize a type name
>> syntactically, since type names consist of sequences of keywords
>> and symbols ((), [], *). (An identifier that's an enumeration
>> constant can appear in a type name, but only between [].) A typedef
>> effectively creates a new context-sensitive keyword, requiring the
>> parser to refer to the symbol table to recognize it.
>>
>> In a new language with a carefully designed syntax, it should be
>> possible to recognize type names syntactically, even type names
>> that are single identifiers.
>
> That's quite hard even with special syntax.
>
> The most foolproof way is to use a keyword to introduce a type specifier:
>
> declare A B;
>
> A is a type, B is a variable name. Otherwise you're looking at:
>
> A B;
>
> Here, you might be able to say that two adjacent identifiers can only
> occur if the first is a type-name. But this sounds a bit fragile. (And
> type names could be dotted sequences depending on language: A.B.C D)
>
> When seeing a set of function parameters such as (A,B,C,D), are these
> all types with no parameter names, or all parameter names with no type?
In C, you can't tell without knowing whether A, B, C, and D are type
names or not. In a new language sensibly designed without being tied to
backward compatibility, the question wouldn't arise; there would be one
consistent syntax for function declarations. And if the language is at
all strongly typed, it wouldn't be possible to define function
parameters without specifying their types.
> How about casts: the C-style (A)(B) could be casting B to type A, or it
> can be calling function A with parameter B. Or both could be casts.
Sure, if you use C's cast syntax for type conversions and permit the
function name in a call to be parenthesized.
If you want C, you know where to find it -- but I thought the whole
point is that you don't.
> It's not impossible, but having types declared ahead of use makes many
> things easier and the language design more flexible.
Having *everything* declared ahead of use makes many things easier.
Again, you can of course do whatever you like in your private language,
but it seems to me that you may be copying some of C's mistakes. If you
want the scope of a declaration to include the entire containing block,
IMHO it's more consistent to apply the same rule to object and type
declarations.
Though personally I prefer to have the scope start with the declaration,
as it's done in C. I think you need to understand that a lot of people
*like* having identifiers be visible only after they've been declared.
You don't have to agree, but you should be aware that the rest of us
aren't just making a virtue of necessity.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-15 12:01 -0700 |
| Message-ID | <c7da8eb9-e609-4150-abb2-bb4c73972eea@googlegroups.com> |
| In reply to | #89181 |
On Wednesday, June 15, 2016 at 1:32:52 PM UTC-5, Keith Thompson wrote: > Though personally I prefer to have the scope start with the declaration, > as it's done in C. I think you need to understand that a lot of people > *like* having identifiers be visible only after they've been declared. > You don't have to agree, but you should be aware that the rest of us > aren't just making a virtue of necessity. I would suggest that the best approach would be to specify that redefining an outer-scope identifier within a block will make it unusable throughout the entire block, but inner-scope identifier would not become usable until its point of declaration. Cases where an outer-scope identifier is used within a block that subsequently reuses the name are likely to represent coding mistakes. [Incidentally, I'd like to see the same principle applied to issues of case- sensitivity; in cases where there's an outer-scope identifier called X and an inner-scope identifier called x, I find compelling both the arguments from advocates of case-sensitivity that someone wanting to use x should use its proper name, rather than X, and the arguments from advocates of case- insensitivity that someone who wants the outer-scope variable X to remain useful should give the inner-scope variable a more-distinct name. The solution IMHO should not be to have the language be entirely case-sensitive or entirely case-insensitive, but instead say that if there is an inner-scope identifier called x, the name X will be unusable within that scope, even if it has a name in an outer scope. Obviously there exists C code which would be rejected by such a rule, so adding it to C would not be good unless there were ways to explicitly enable or disable such behavior, but aside from allowing compatibility with existing code I don't see much advantage to allowing names which neither match perfectly nor differ in more than case or other fine representational details (e.g. given that some editors may replace a combining grave accent followed by an "a" with a single "a with grave accent" character or vice versa, allowing an inner-scope identifier to use one while an outer-scope identifier uses the other would mean that editing code which tries to use one of those variables might turn it into code that uses the other.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-15 20:15 +0100 |
| Message-ID | <njs9gt$1qk$1@dont-email.me> |
| In reply to | #89186 |
On 15/06/2016 20:01, supercat@casperkitty.com wrote: > On Wednesday, June 15, 2016 at 1:32:52 PM UTC-5, Keith Thompson wrote: >> Though personally I prefer to have the scope start with the declaration, >> as it's done in C. I think you need to understand that a lot of people >> *like* having identifiers be visible only after they've been declared. >> You don't have to agree, but you should be aware that the rest of us >> aren't just making a virtue of necessity. > > I would suggest that the best approach would be to specify that redefining > an outer-scope identifier within a block will make it unusable throughout > the entire block, but inner-scope identifier would not become usable until > its point of declaration. Cases where an outer-scope identifier is used > within a block that subsequently reuses the name are likely to represent > coding mistakes. Yes, exactly. A block that makes use of two different instances of a name, switching part-way through, has something definitely 'off' about it. And it wouldn't take much copy&pasting in the block (ie. normal editing) for a reference to an outer 'A' to end up after the declaration for the distinct inner 'A'. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web