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 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-15 23:28 +0100 |
| Message-ID | <njskpp$ctg$1@dont-email.me> |
| In reply to | #89213 |
On 15/06/2016 22:42, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 15/06/2016 21:38, Keith Thompson wrote:
>> 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
> (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.)
I look at this from the implementation POV as well. I see it as a
problem that a block can be associated with two identical names at the
same 'time', and with an untidy 'switch-over' somewhere along the block.
Simply avoiding such a situation isn't really dealing with it; the
implementation still needs to support it. Other people's code can have
it. The possibility is always there.
I've noticed also that this appears not to be legal:
{int A;
{if (cond) int A;
You apparently can't have a declaration as the sole statement of an If
or Loop statement. Which clearly would have created some problems! But
you can however write this:
{int A;
{ if (!cond) goto L1;
int A;
L1:
A=20;
So, if cond is false, is the inner A being set to 20, or the outer one?
Comment sense says it's the inner one, even if the declaration is
skipped; presumably it's not an actual executable statement, the
variable is always created. (Unless it's initialised I suppose.)
> **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?
When a reference to a name precedes its declaration, the answers simply
aren't clear-cut.
It wouldn't bother me if the example was legal and worked as expected.
But I thought you liked the fact that (i) names ought to be declared
befor use; and (ii) the point of having declarations in odd places was
*so* you can declare a variable at it's first point of use.
Then you might want to do something about that, which can include making
the code generate an error.
However the problem with making the above work (setting the inner n to
20), is that currently C works differently (it will set an outer n to 20
if there is one visible, or an error is raised).
But I'm not too bothered provided there is a one name-per-block policy.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-15 15:35 -0700 |
| Message-ID | <5e99ba09-0d29-476b-b566-172a6abc923c@googlegroups.com> |
| In reply to | #89224 |
On Wednesday, June 15, 2016 at 5:28:16 PM UTC-5, Bart wrote:
> You apparently can't have a declaration as the sole statement of an If
> or Loop statement. Which clearly would have created some problems! But
> you can however write this:
>
> {int A;
> { if (!cond) goto L1;
> int A;
> L1:
> A=20;
>
> So, if cond is false, is the inner A being set to 20, or the outer one?
> Comment sense says it's the inner one, even if the declaration is
> skipped; presumably it's not an actual executable statement, the
> variable is always created. (Unless it's initialised I suppose.)
Things get more fun if you add branches back to a spot in the block
before a variable was created (part of the reason for the requirement
that declarations appear at the beginning of a statement may have been
a desire to prevent goto labels from appearing before them). According
to the Standard, if execution flows through a declaration, the value of
the variable in question becomes Indeterminate, but branching from a spot
after a declaration to a spot before, or vice versa, will not affect the
value of a variable.
So one could start a block by jumping to a spot after the declaration of
a variable which shared its name with an outer-scope variable, setting
the inner variable's value, then jump to a spot before its declaration,
manipulate the outer variable's value, then jump to a spot after the
declaration, and resume working with the inner-scope variable which will
still have kept its value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 16:48 -0700 |
| Message-ID | <ln4m8uxbcq.fsf@kst-u.example.com> |
| In reply to | #89224 |
BartC <bc@freeuk.com> writes:
> On 15/06/2016 22:42, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 15/06/2016 21:38, Keith Thompson wrote:
>
>>> 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
>
>> (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.)
>
> I look at this from the implementation POV as well. I see it as a
> problem that a block can be associated with two identical names at the
> same 'time', and with an untidy 'switch-over' somewhere along the block.
> Simply avoiding such a situation isn't really dealing with it; the
> implementation still needs to support it. Other people's code can have
> it. The possibility is always there.
>
> I've noticed also that this appears not to be legal:
>
> {int A;
> {if (cond) int A;
Of course not. It's a syntax error. The syntax for an if statement is
if ( expression ) statement
and a declaration is not a statement (though it can be part of a
statement).
> You apparently can't have a declaration as the sole statement of an If
> or Loop statement. Which clearly would have created some problems! But
> you can however write this:
>
> {int A;
> { if (!cond) goto L1;
> int A;
> L1:
> A=20;
Right.
> So, if cond is false, is the inner A being set to 20, or the outer one?
> Comment sense says it's the inner one, even if the declaration is
> skipped; presumably it's not an actual executable statement, the
> variable is always created. (Unless it's initialised I suppose.)
That's some ugly code, but it's unambiguous. `goto L1;` is a statement,
so there's no syntactic problem with the if statement. The presence of
the label `L1:` doesn't affect scoping. So the assignment `A=20;`
refers to the inner `int A;` defined two lines above, not the one
defined in an outer scope. (If `A` were initialized and the goto were
executed, it would skip over the initialazation; `A` would exist but
would have an indeterminate value. So don't 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?
>
> When a reference to a name precedes its declaration, the answers simply
> aren't clear-cut.
Then what's the bloody point? You propose a language change to extend
the scope of a declaration, but in the only cases where it could
possibly matter "the answers simply aren't clear-cut". The answers
certainly *could* be clear-cut if you wanted to make them so.
> It wouldn't bother me if the example was legal and worked as expected.
> But I thought you liked the fact that (i) names ought to be declared
> befor use; and (ii) the point of having declarations in odd places was
> *so* you can declare a variable at it's first point of use.
(*sigh*)
As I've already said, I personally dislike your proposal. Given that,
I've still been trying to find out just what your proposal is.
Yes, names ought to be declared before use. In C, they *have* to be.
Why are you proposing a change that would permit variables to be used
before declared?
Or are you proposing such a change? I can't tell.
> Then you might want to do something about that, which can include making
> the code generate an error.
As a C compiler will already do, with no changes to the language.
> However the problem with making the above work (setting the inner n to
> 20), is that currently C works differently (it will set an outer n to 20
> if there is one visible, or an error is raised).
>
> But I'm not too bothered provided there is a one name-per-block policy.
I give up. (I probably should have done so sooner.)
--
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-16 01:11 +0100 |
| Message-ID | <njsqsf$tg8$1@dont-email.me> |
| In reply to | #89237 |
On 16/06/2016 00:48, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> When a reference to a name precedes its declaration, the answers simply >> aren't clear-cut. > > Then what's the bloody point? You propose a language change to extend > the scope of a declaration, but in the only cases where it could > possibly matter "the answers simply aren't clear-cut". The answers > certainly *could* be clear-cut if you wanted to make them so. But it doesn't matter! The main point of the proposal is not to have two versions of a name visible within the main block (eg. inner A and outer A at different points in the block). Extending the scope of a declaration to the entire block will do exactly that. That's 90% of the job done, as more global versions will be hidden, or shadowed, throughout the block. The rest is just bickering what should be done in the case of declarations of a name that follow the use of the name in that block. The answer is that it's not important, so long as that name doesn't refer to any other version of it. As to what could be done about this, I've gone over the possibilities a few times, and even supercat has chipped in, so I don't see any point in doing it again. Allow it, disallow it, it doesn't matter, as in most cases people will write the declaration first. (FWIW, how I implement this outside C is that the declaration of a name, in any block in a function, extends not only to the entire block, but to the whole function. And there is no problem with names used before their declarations (except for user-types), although I rarely make use of that for local names. >> But I'm not too bothered provided there is a one name-per-block policy. > > I give up. (I probably should have done so sooner.) Do you understand what the one-name-per-block policy is about? If not then that then will explain why you can't make head or tail of my proposal. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 18:01 -0700 |
| Message-ID | <lnvb1avtdm.fsf@kst-u.example.com> |
| In reply to | #89241 |
BartC <bc@freeuk.com> writes:
> On 16/06/2016 00:48, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
[...]
>>> But I'm not too bothered provided there is a one name-per-block policy.
>>
>> I give up. (I probably should have done so sooner.)
>
> Do you understand what the one-name-per-block policy is about? If not
> then that then will explain why you can't make head or tail of my proposal.
I think "one name per block" is a confusing way to express the idea.
You object to the fact that the same name can refer to different
entities depending on where you are in the block, right?
{
int a;
{
a = 10; // refers to the outer `a`
int a;
a = 20; // refers to the inner `a`
}
}
The *scope* of an identifier is by definition the region of program text
in which it's visible (N1570 6.2.1p2). So when you talk about extending
the *scope* of an identifier, that tells me you want it to be *visible*
over a wider range of program text.
Logically, such a change would affect the simpler case I presented:
{
a = 10;
int a;
}
In fact you don't care whether the inner `a` in the first example above
is visible before its declaration or not. Your entire point is to
ensure that the outer `a` is *not* visible over the entire inner block.
I got caught up on what you were actually saying, as opposed to what you
meant.
Here's a different way to solve the problem:
Constraint:
An identifier shall not be redeclared in an inner block if an outer
occurrence of the same identifier has been referred to in the same
block prior to the redeclaration.
(I haven't spent enough time to get the wording just right.)
It requires no change to the scoping rules. It just requires a
diagnostic for the case that bothers you.
I do not advocate any such change. Compiling with "gcc -Wshadow"
suffices to avoid the problem with no language changes (admittedly
that doesn't help if you're using a compiler that doesn't have
"-Wshadow" or equivalent). I haven't found shadowing to be a
problem worth solving anyway; I might have run into it a small
handful of times. But if you wanted to change the language to
avoid the problem, I suggest that's a better way to do it.
--
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 18:44 -0700 |
| Message-ID | <6fb7e5ff-76fd-4105-8b55-7c68baa7fa08@googlegroups.com> |
| In reply to | #89243 |
On Wednesday, June 15, 2016 at 8:02:08 PM UTC-5, Keith Thompson wrote: > Here's a different way to solve the problem: > > Constraint: > > An identifier shall not be redeclared in an inner block if an outer > occurrence of the same identifier has been referred to in the same > block prior to the redeclaration. > > (I haven't spent enough time to get the wording just right.) How about: "No variable or type shall be declared with the same name as any variable or type which has been previously declared or referenced within the same block"? You know the Standard's terminology better than I, but given "int x;" at an outer or file scope, I think that "int x;" within a function is considered a declaration whose name coincidentally happens to match and shadow the outer variable, but does not "redeclare" or otherwise affect the outer variable in any way.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-15 19:42 -0700 |
| Message-ID | <lnr3bxx3as.fsf@kst-u.example.com> |
| In reply to | #89245 |
supercat@casperkitty.com writes:
> On Wednesday, June 15, 2016 at 8:02:08 PM UTC-5, Keith Thompson wrote:
>> Here's a different way to solve the problem:
>>
>> Constraint:
>>
>> An identifier shall not be redeclared in an inner block if an outer
>> occurrence of the same identifier has been referred to in the same
>> block prior to the redeclaration.
>>
>> (I haven't spent enough time to get the wording just right.)
>
> How about: "No variable or type shall be declared with the same name as
> any variable or type which has been previously declared or referenced
> within the same block"?
You can't redeclare something that's been declared within the same
block, so that part is unnecessary.
> You know the Standard's terminology better than I, but given "int x;" at
> an outer or file scope, I think that "int x;" within a function is
> considered a declaration whose name coincidentally happens to match and
> shadow the outer variable, but does not "redeclare" or otherwise affect
> the outer variable in any way.
Yes -- which is why I wrote about redeclaring the *identifier*, not the
declared entity. No doubt it could be phrased better. But since I
don't think it's a particularly good idea in the first place, I'm not
going to bother.
--
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-16 13:06 +0100 |
| Message-ID | <nju4og$e7v$1@dont-email.me> |
| In reply to | #89241 |
On 16/06/2016 01:11, BartC wrote:
> (FWIW, how I implement this outside C is that the declaration of a name,
> in any block in a function, extends not only to the entire block, but to
> the whole function.
I've looked at some more aspects of block-scopes. If I try this code:
{
int* p;
{
int A = 77;
p = &A;
}
printf("*p=%d\n", *p);
}
then none of compilers I tried gives any sort of warning about it. (That
is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given -Wall
-Wextra -Wpedantic and the output was not filtered.)
All also display '77', except gcc that displays '0' when optimised;
unoptimised, it also shows '77'.
So it does seem that block-scopes could lead to more subtle bugs
compared to having only function-wide scopes. Unless perhaps someone has
a counter-example that shows the opposite?
Note that in my example, the intention was that the 'int A' is only
where it is to conform to the style that variables are declared where
they are first used, not necessarily to restrict its scope.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-16 15:06 +0200 |
| Message-ID | <nju897$qhn$1@dont-email.me> |
| In reply to | #89258 |
On 16/06/16 14:06, BartC wrote:
> On 16/06/2016 01:11, BartC wrote:
>
>> (FWIW, how I implement this outside C is that the declaration of a name,
>> in any block in a function, extends not only to the entire block, but to
>> the whole function.
>
> I've looked at some more aspects of block-scopes. If I try this code:
>
> {
> int* p;
> {
> int A = 77;
> p = &A;
> }
> printf("*p=%d\n", *p);
> }
>
>
> then none of compilers I tried gives any sort of warning about it. (That
> is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given -Wall
> -Wextra -Wpedantic and the output was not filtered.)
gcc warns about it - though the warning is the slightly cryptic
"warning: 'A' is used uninitialized in this function".
(I assume you know that some of the warnings that compilers can generate
require advanced analysis passes that are only enabled when optimisation
is enabled? Always use at least -O1.)
However, I think compilers should definitely warn about such cases, if
they can spot them - after all, it is undefined behaviour that can be
seen at compile time. gcc and clang get more warnings at every new
version, but they don't warn about every possible mistake. There is
clearly room for improvement in this case.
>
> All also display '77', except gcc that displays '0' when optimised;
> unoptimised, it also shows '77'.
It's undefined behaviour, so these are all equally valid.
>
> So it does seem that block-scopes could lead to more subtle bugs
> compared to having only function-wide scopes. Unless perhaps someone has
> a counter-example that shows the opposite?
I can agree that block scopes can lead to subtle bugs - but so can most
aspects of programming. Limiting local scopes (or, as I think you
actually mean, limiting lifetimes) to function-wide only will mean that
you avoid this particular type of bug. Thinking about the code you
write will also help you avoid it. And having your variables alive
throughout the function does not in any way make your code more correct
when you mess up the order of variable assignments and variable usage -
it merely means that you get well-defined and consistent incorrect code
instead of undefined behaviour of incorrect code. And of course the
cost of your limitations is that you separate the definition of
variables from their usage, making code harder to read, write and maintain.
>
> Note that in my example, the intention was that the 'int A' is only
> where it is to conform to the style that variables are declared where
> they are first used, not necessarily to restrict its scope.
>
I don't understand what you mean here. If "int A" were anywhere else,
it would either be a syntax error (if it came after "p = &A;"), or if it
came before the start of the inner block it would be perfectly simple,
correct code that fails to demonstrate your problem.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-16 14:40 +0100 |
| Message-ID | <njua9d$28q$1@dont-email.me> |
| In reply to | #89261 |
On 16/06/2016 14:06, David Brown wrote: > On 16/06/16 14:06, BartC wrote: >> then none of compilers I tried gives any sort of warning about it. (That >> is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given -Wall >> -Wextra -Wpedantic and the output was not filtered.) > > gcc warns about it - though the warning is the slightly cryptic > "warning: 'A' is used uninitialized in this function". > > (I assume you know that some of the warnings that compilers can generate > require advanced analysis passes that are only enabled when optimisation > is enabled? Always use at least -O1.) No, I didn't know that. But it suggests that with -O0, the code is fine. Which it won't be if developed with -O0 (which can happen to get faster turnaround), but compiled by someone else with -O3. So, the conclusion is to always compile with the highest optimisation as an extra final test? But that might only work with gcc. You can't rely on a specific compiler with a specific option to take some of the danger out of a somewhat risky coding practice. >> Note that in my example, the intention was that the 'int A' is only >> where it is to conform to the style that variables are declared where >> they are first used, not necessarily to restrict its scope. >> > > I don't understand what you mean here. If "int A" were anywhere else, > it would either be a syntax error (if it came after "p = &A;"), or if it > came before the start of the inner block it would be perfectly simple, > correct code that fails to demonstrate your problem. I mean that its placement could be arbitrary. Perhaps based on well-meaning intentions to declare variables as close to where they are first used as possible. Even if you do a quick check to see if it's referenced within a wider scope, you can easily miss that indirect access. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-16 09:09 -0700 |
| Message-ID | <lneg7xw1xo.fsf@kst-u.example.com> |
| In reply to | #89266 |
BartC <bc@freeuk.com> writes:
> On 16/06/2016 14:06, David Brown wrote:
>> On 16/06/16 14:06, BartC wrote:
> >> then none of compilers I tried gives any sort of warning about it. (That
> >> is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given -Wall
> >> -Wextra -Wpedantic and the output was not filtered.)
> >
> > gcc warns about it - though the warning is the slightly cryptic
> > "warning: 'A' is used uninitialized in this function".
> >
> > (I assume you know that some of the warnings that compilers can generate
> > require advanced analysis passes that are only enabled when optimisation
> > is enabled? Always use at least -O1.)
>
> No, I didn't know that. But it suggests that with -O0, the code is fine.
> Which it won't be if developed with -O0 (which can happen to get faster
> turnaround), but compiled by someone else with -O3.
No the code is not "fine". The code has undefined behavior that the
compiler failed to diagnose.
[...]
--
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 | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2016-06-17 20:51 +0800 |
| Message-ID | <nk0ro2$5kj$2@dont-email.me> |
| In reply to | #89297 |
Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 16/06/2016 14:06, David Brown wrote: >>> On 16/06/16 14:06, BartC wrote: >> >> then none of compilers I tried gives any sort of warning about it. >> >> (That is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given >> >> -Wall -Wextra -Wpedantic and the output was not filtered.) >> > >> > gcc warns about it - though the warning is the slightly cryptic >> > "warning: 'A' is used uninitialized in this function". >> > >> > (I assume you know that some of the warnings that compilers can >> > generate require advanced analysis passes that are only enabled when >> > optimisation >> > is enabled? Always use at least -O1.) >> >> No, I didn't know that. But it suggests that with -O0, the code is fine. >> Which it won't be if developed with -O0 (which can happen to get faster >> turnaround), but compiled by someone else with -O3. > > No the code is not "fine". The code has undefined behavior that the > compiler failed to diagnose. > > [...] For some people code seems to be "fine" if the compiler does not complain and the program does crash immediately. Others just have higher expectations. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 10:32 +0200 |
| Message-ID | <nk0cjn$k1d$1@dont-email.me> |
| In reply to | #89266 |
On 16/06/16 15:40, BartC wrote: > On 16/06/2016 14:06, David Brown wrote: >> On 16/06/16 14:06, BartC wrote: > > >>> then none of compilers I tried gives any sort of warning about it. (That >>> is, Pelles C, lccwin, DMC, gcc, TCC and clang. gcc was given -Wall >>> -Wextra -Wpedantic and the output was not filtered.) >> >> gcc warns about it - though the warning is the slightly cryptic >> "warning: 'A' is used uninitialized in this function". >> >> (I assume you know that some of the warnings that compilers can generate >> require advanced analysis passes that are only enabled when optimisation >> is enabled? Always use at least -O1.) > > No, I didn't know that. But it suggests that with -O0, the code is fine. > Which it won't be if developed with -O0 (which can happen to get faster > turnaround), but compiled by someone else with -O3. > > So, the conclusion is to always compile with the highest optimisation as > an extra final test? But that might only work with gcc. Code that "only works with optimisation disabled" is, IMHO, broken code. I know of no good reason to compile with optimisation disabled - compilation with "-O0" is not much faster than "-O1" (higher levels get slower), and with "-O1" you get generated assembly that is much easier to understand as well as being significantly more efficient, and you get better static analysis. Personally, I use either -O2 or -Os (depending on the type of target) for almost all compilation, including during debugging. I sometimes step down to -O1 if I want code that is easy for single-stepping at the assembly level (that is occasionally useful in my line of work). Of course, details will vary by compiler - those flags are for gcc. But testing with optimisation flags is not something to leave as an "extra final test". If you are shipping the result as binaries, test what you will ship, and ship what you test - do most of your development using the appropriate flags. If you are shipping source code, you must regularly check builds with a wide variety of flags. > > You can't rely on a specific compiler with a specific option to take > some of the danger out of a somewhat risky coding practice. The "risky coding practice" in this case is incorrect code with undefined behaviour. And you make use of every tool you have on hand in order to reduce the chances of that happening - including compiling with whatever flags are necessary to help the compiler spot /your/ mistakes. If you are feeling really enthusiastic, you might also like to use your brain and apply a little thought to what you write - I find that's a good way to avoid code errors. And note that it is /you/ who finds the error here - you are not relying on end user's choice of compiler or flags. > >>> Note that in my example, the intention was that the 'int A' is only >>> where it is to conform to the style that variables are declared where >>> they are first used, not necessarily to restrict its scope. >>> >> >> I don't understand what you mean here. If "int A" were anywhere else, >> it would either be a syntax error (if it came after "p = &A;"), or if it >> came before the start of the inner block it would be perfectly simple, >> correct code that fails to demonstrate your problem. > > I mean that its placement could be arbitrary. Perhaps based on > well-meaning intentions to declare variables as close to where they are > first used as possible. Even if you do a quick check to see if it's > referenced within a wider scope, you can easily miss that indirect access. > As I said, the placement cannot be arbitrary in this example. You are still making no sense to me.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 11:00 +0100 |
| Message-ID | <nk0hne$4k1$1@dont-email.me> |
| In reply to | #89374 |
On 17/06/2016 09:32, David Brown wrote:
> On 16/06/16 15:40, BartC wrote:
>> I mean that its placement could be arbitrary. Perhaps based on
>> well-meaning intentions to declare variables as close to where they are
>> first used as possible. Even if you do a quick check to see if it's
>> referenced within a wider scope, you can easily miss that indirect access.
>>
>
> As I said, the placement cannot be arbitrary in this example. You are
> still making no sense to me.
Yes it can.
You use a variable A for the first time at some point P in function. You
can choose to declare A anywhere between the start of the function, and
P. That choice can be arbitrary. It is, however, sensitive to the number
of intervening { between the declaration, and the first use.
Those {, or some of them, may not exist when the choice made. Some could
be added or removed later, perhaps by someone else; that makes the use
of block scopes somewhat more fragile, *IMO*, than function scopes in
general.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 12:59 +0200 |
| Message-ID | <nk0l5l$fu4$1@dont-email.me> |
| In reply to | #89383 |
On 17/06/16 12:00, BartC wrote:
> On 17/06/2016 09:32, David Brown wrote:
>> On 16/06/16 15:40, BartC wrote:
>
>>> I mean that its placement could be arbitrary. Perhaps based on
>>> well-meaning intentions to declare variables as close to where they are
>>> first used as possible. Even if you do a quick check to see if it's
>>> referenced within a wider scope, you can easily miss that indirect
>>> access.
>>>
>>
>> As I said, the placement cannot be arbitrary in this example. You are
>> still making no sense to me.
>
> Yes it can.
Where else, in /your example/, can you put "int A" ?
{
int* p;
{
int A = 77;
p = &A;
}
printf("*p=%d\n", *p);
}
If you put it before the second {, then you are no longer demonstrating
the problem you had caused - A has a long enough lifetime (and scope)
for the use of *p to be defined.
If you put it after the "p = &A;" line, then the program will not compile.
>
> You use a variable A for the first time at some point P in function. You
> can choose to declare A anywhere between the start of the function, and
> P. That choice can be arbitrary.
The choice is not "arbitrary", unless you program randomly. The choice
is often dictated by rules - either the rules of the language you use
(such as limitations in C90), rules of your coding standards. If you
are free to choose, then you don't make an arbitrary decision - you pick
the "best" place, which will almost certainly be either at first use, at
the start of the narrowest possible block for the task in hand, or at
the start of the function.
> It is, however, sensitive to the number
> of intervening { between the declaration, and the first use.
No, it does not matter how many blocks are opened between declaring the
variable and using it. It matters how many blocks are /closed/ before
its last use - the variable needs to have a lifetime as long as it is in
use.
>
> Those {, or some of them, may not exist when the choice made. Some could
> be added or removed later, perhaps by someone else; that makes the use
> of block scopes somewhat more fragile, *IMO*, than function scopes in
> general.
>
Add them or remove them as needed - it doesn't matter. It does not make
anything "fragile".
And if you declare your variables when you first use them, then you will
not be able to add { between the declaration and usage.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 12:34 +0100 |
| Message-ID | <nk0n8k$n8c$1@dont-email.me> |
| In reply to | #89390 |
On 17/06/2016 11:59, David Brown wrote:
> On 17/06/16 12:00, BartC wrote:
>> Yes it can.
>
> Where else, in /your example/, can you put "int A" ?
>
>
> {
> int* p;
> {
> int A = 77;
> p = &A;
> }
> printf("*p=%d\n", *p);
> }
>
> If you put it before the second {, then you are no longer demonstrating
> the problem you had caused - A has a long enough lifetime (and scope)
> for the use of *p to be defined.
>
> If you put it after the "p = &A;" line, then the program will not compile.
Exactly. Even in this minimal example, there's a choice! Considering
only the first two, both will compile, both might work (depending on
compiler), but one has a subtle bug.
> Add them or remove them as needed - it doesn't matter. It does not make
> anything "fragile".
>
> And if you declare your variables when you first use them, then you will
> not be able to add { between the declaration and usage.
You start with this:
{
{
int A=0;
A;
Then the code changes and a prior reference is needed:
{
{ A;
int A=0;
A;
Now it is necessary to move the declaration, but it you forget, the A
might match an outer A (unless you're fortunate enough to use gcc and
remember all the right options).
Or if is necessary to create a new block like this (obviously with other
bits of code not shown):
{
{
if (C)
{ int A=0;
}
A;
Now that last reference A is cut off from its declaration.
There are a million ways of this causing problems. But you're dismissing
this potential for bugs and general hassle by saying:
(1) A programmer should be more vigilant
(2) A programmer should use a compiler such as gcc with dozens
of options enabled to help catch such problems
To me, that is unsatisfactory. Why should a language go to the trouble
of allowing shadowing between block scope variables, then someone else
has to go to the further trouble of detecting such shadowing in the
compiler?!
And of course many compilers won't have that ability. It seems utterly
pointless.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 13:56 +0200 |
| Message-ID | <nk0ohd$rjo$1@dont-email.me> |
| In reply to | #89394 |
On 17/06/16 13:34, BartC wrote:
> On 17/06/2016 11:59, David Brown wrote:
>> On 17/06/16 12:00, BartC wrote:
>
>>> Yes it can.
>>
>> Where else, in /your example/, can you put "int A" ?
>>
>>
>> {
>> int* p;
>> {
>> int A = 77;
>> p = &A;
>> }
>> printf("*p=%d\n", *p);
>> }
>>
>> If you put it before the second {, then you are no longer demonstrating
>> the problem you had caused - A has a long enough lifetime (and scope)
>> for the use of *p to be defined.
>>
>> If you put it after the "p = &A;" line, then the program will not
>> compile.
>
> Exactly. Even in this minimal example, there's a choice! Considering
> only the first two, both will compile, both might work (depending on
> compiler), but one has a subtle bug.
Yes, there is a choice - in the same sense that you can write complete
nonsense in any manner that you like.
For people who can program in C, there is no choice in this example -
"int A" has to go before the second {.
For people who have bizarre ideas about the evils of block scope and
want to make up unrealistic examples to "prove" it, there is no choice -
"int A" has to go inside the inner block.
>
>
>> Add them or remove them as needed - it doesn't matter. It does not make
>> anything "fragile".
>>
>> And if you declare your variables when you first use them, then you will
>> not be able to add { between the declaration and usage.
>
> You start with this:
> {
> {
> int A=0;
> A;
>
> Then the code changes and a prior reference is needed:
>
> {
> { A;
> int A=0;
> A;
The obvious answer here is - don't do that. If you want your code to
keep working, don't hire ignorant amateurs to do the work. Find someone
who understands at least the basics of the programming language, and is
capable of reading the code before messing it up.
>
> Now it is necessary to move the declaration, but it you forget, the A
> might match an outer A (unless you're fortunate enough to use gcc and
> remember all the right options).
The inner "A" will only match the outer "A" and cause such troubles if
the programmer is thoughtless enough to call everything "A" - in
addition to being unable to read, unable to program, and unwilling to
think before messing about with code. You have got to get a great many
things wrong in program development before this one becomes a likely
issue - and it will never be a significant problem compared to all the
others that hit first.
>
> Or if is necessary to create a new block like this (obviously with other
> bits of code not shown):
>
> {
> {
> if (C)
> { int A=0;
> }
> A;
>
> Now that last reference A is cut off from its declaration.
>
> There are a million ways of this causing problems. But you're dismissing
> this potential for bugs and general hassle by saying:
>
> (1) A programmer should be more vigilant
> (2) A programmer should use a compiler such as gcc with dozens
> of options enabled to help catch such problems
No, I am merely saying that the programmer should be able to program.
Using tools like gcc for static error checking is a great tool to help
catch small errors or mistakes. It is not a replacement for thought, or
competent programmers, but it can be helpful. I like my tools to be
able to spot as many mistakes as possible, and I think it is folly for
developers /not/ to use the abilities of the tools they have
conveniently available in order to provide such checking. But I also
expect programmers to write reasonable code - and you don't have to be
an expert to avoid making mistakes like this one.
>
> To me, that is unsatisfactory. Why should a language go to the trouble
> of allowing shadowing between block scope variables, then someone else
> has to go to the further trouble of detecting such shadowing in the
> compiler?!
The language allows block scope variables and mixing statements and
declarations because programmers find that very helpful in being more
efficient developers, and writing clearer and more maintainable code.
If you consider yourself to be so poor a programmer, and so error-prone
in your coding, that this is a big problem for you, then you are welcome
to define all your variables at the start of your functions. Most
programmers, on the other hand, will use a little more of the
flexibility allowed by the language in order to write "better" code (for
whatever definition of "better" they choose).
>
> And of course many compilers won't have that ability. It seems utterly
> pointless.
>
All C compilers allow you to define variables at block scope. If they
don't, they are not C compilers. I don't even know of any C-subset
compilers that have trouble with this. Clearly C90 compilers will not
allow declarations after statements (or if they do, it is as a C99
compatible extension).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-06-17 13:15 +0100 |
| Message-ID | <nk0plt$vk2$1@dont-email.me> |
| In reply to | #89395 |
On 17/06/2016 12:56, David Brown wrote:
> On 17/06/16 13:34, BartC wrote:
>> On 17/06/2016 11:59, David Brown wrote:
>>> On 17/06/16 12:00, BartC wrote:
>>
>>>> Yes it can.
>>>
>>> Where else, in /your example/, can you put "int A" ?
>>>
>>>
>>> {
>>> int* p;
>>> {
>>> int A = 77;
>>> p = &A;
>>> }
>>> printf("*p=%d\n", *p);
>>> }
>>>
>> Exactly. Even in this minimal example, there's a choice! Considering
>> only the first two, both will compile, both might work (depending on
>> compiler), but one has a subtle bug.
>
> Yes, there is a choice - in the same sense that you can write complete
> nonsense in any manner that you like.
>
> For people who can program in C, there is no choice in this example -
> "int A" has to go before the second {.
If you start off with this:
{
int* p;
{
int A = 77;
}
printf("*p=%d\n", *p);
}
Then there is no reason why the int A can't go inside the second lot of
braces. I understand that this is encouraged by people who want the
smallest enclosing scope.
The problem comes when the 'p = &A' line is added. *Now*, the int A has
to be moved outside:
{
int* p;
int A;
{
A = 77;
p = &A;
}
printf("*p=%d\n", *p);
}
Another problem being to realise that that is needed, as the compiler
may or may not help.
Then, someone decides they don't need the 'p = &A' any more, and the
game of musical chairs continues as the 'int A' is moved back inside in
an attempt to maintain the smallest possible scope for all variables:
{
int* p;
{
int A = 77;
}
printf("*p=%d\n", *p);
}
This is the sort of nonsense I object to. Just keep the 'int A' at
function scope and be done with it.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-06-17 14:33 +0200 |
| Message-ID | <nk0qnh$3n3$1@dont-email.me> |
| In reply to | #89398 |
On 17/06/16 14:15, BartC wrote:
> On 17/06/2016 12:56, David Brown wrote:
>> On 17/06/16 13:34, BartC wrote:
>>> On 17/06/2016 11:59, David Brown wrote:
>>>> On 17/06/16 12:00, BartC wrote:
>>>
>>>>> Yes it can.
>>>>
>>>> Where else, in /your example/, can you put "int A" ?
>>>>
>>>>
>>>> {
>>>> int* p;
>>>> {
>>>> int A = 77;
>>>> p = &A;
>>>> }
>>>> printf("*p=%d\n", *p);
>>>> }
>>>>
>
>>> Exactly. Even in this minimal example, there's a choice! Considering
>>> only the first two, both will compile, both might work (depending on
>>> compiler), but one has a subtle bug.
>>
>> Yes, there is a choice - in the same sense that you can write complete
>> nonsense in any manner that you like.
>>
>> For people who can program in C, there is no choice in this example -
>> "int A" has to go before the second {.
>
> If you start off with this:
>
> {
> int* p;
> {
> int A = 77;
> }
> printf("*p=%d\n", *p);
> }
>
> Then there is no reason why the int A can't go inside the second lot of
> braces. I understand that this is encouraged by people who want the
> smallest enclosing scope.
That's fine if A is only used inside the inner scope - which is usually
the case.
>
> The problem comes when the 'p = &A' line is added. *Now*, the int A has
> to be moved outside:
>
> {
> int* p;
> int A;
> {
> A = 77;
> p = &A;
> }
> printf("*p=%d\n", *p);
> }
That's correct - at least, sort of correct.
If you were going to take the address of A and use it in the outer
scope, you would probably have defined A in the other scope in the first
place.
It is true that /if/ you have code with a variable in an inner scope,
and you then take its address and use that outside the scope (or, more
importantly, outside its lifetime - but for a local variable like this
the two coincide), then you will have to modify the code to make it work.
But honestly, how often is this going to occur? Approximately never,
would be my rough estimate. The great majority of local variables are
used locally, and can be declared and used within a small scope. And
any time you ever take the address of a variable, you need to think
about its lifetime - this is not something that only applies to
block-local variables. It applies to /every/ variable whose address is
taken.
You can equally well say that if you have called the variable "A" and
later want to use "p = &B;" to refer to it, then you have to go back and
rename the variable - and use that as an argument for saying that all
variables should be called "B" in the first place.
>
> Another problem being to realise that that is needed, as the compiler
> may or may not help.
>
> Then, someone decides they don't need the 'p = &A' any more, and the
> game of musical chairs continues as the 'int A' is moved back inside in
> an attempt to maintain the smallest possible scope for all variables:
>
> {
> int* p;
> {
> int A = 77;
> }
> printf("*p=%d\n", *p);
> }
It is not necessary to move the variable back into the inner scope
again. It might make sense during code cleanup, but if you are in heavy
development and changing the function round a lot, then probably you
will want to wait if you might want to put "p = &A" in again.
There is no law against using common sense when coding.
>
> This is the sort of nonsense I object to. Just keep the 'int A' at
> function scope and be done with it.
>
/You/ can put it where you like in /your/ code. But accept that other
people see your objections here as nonsense. Writing bad code full of
mistakes and undefined behaviour does not justify a dislike of
block-scope variables, and it will not convince anyone. I am quite
happy to accept that /you/ prefer your local variables to be defined
only at the start of the function - but I don't see that you have any
good logical justification for that preference.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-06-17 08:47 -0400 |
| Message-ID | <nk0rid$67i$1@dont-email.me> |
| In reply to | #89398 |
On 6/17/2016 8:15 AM, BartC wrote:
> [...]
> This is the sort of nonsense I object to. Just keep the 'int A' at
> function scope and be done with it.
Variable names cannot have function scope.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
Page 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web