Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91178 > unrolled thread
| Started by | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-27 22:36 +0200 |
| Last post | 2016-08-01 07:20 -0700 |
| Articles | 20 on this page of 193 — 30 participants |
Back to article view | Back to comp.lang.c
IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-27 22:36 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 16:42 -0700
Re: IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-28 01:47 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 17:20 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 18:03 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 00:43 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:12 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 05:41 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:02 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 06:26 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:45 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 09:11 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 09:30 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-28 14:03 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:24 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 01:14 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:27 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:08 +0200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 11:37 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:51 +0200
Re: IEEE: C is the first programming language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-29 08:36 -0600
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 05:32 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 14:42 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 06:59 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 16:08 +0100
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-29 09:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 09:21 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 17:55 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:00 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:48 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 21:12 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 19:39 -0700
Re: IEEE: C is the first programming language luser droog <luser.droog@gmail.com> - 2016-07-29 14:56 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:54 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-01 10:30 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:13 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 07:34 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 14:10 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 23:36 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 16:04 -0700
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-07-30 11:22 +1200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-30 01:09 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:08 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 21:16 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 22:13 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-02 13:33 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:11 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:36 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 07:51 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:19 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 10:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 11:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 11:49 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 12:37 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 13:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 14:05 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 15:53 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:03 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 10:50 -0700
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-07-28 10:50 +0200
Re: IEEE: C is the first programming language "Osmium" <r124c4u102@comcast.net> - 2016-07-28 08:11 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:46 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 16:50 +0200
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-01 11:18 +0200
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 05:37 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 14:02 +0100
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 07:05 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 16:04 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-01 09:26 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 10:12 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 10:21 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 11:01 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 11:44 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-02 12:05 +0200
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 15:48 +0000
Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-02 20:09 -0400
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 06:42 +0000
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:02 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-03 03:15 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 11:53 +0000
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-03 08:57 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-03 10:52 +0200
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:09 +0100
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-03 08:51 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 10:51 +0100
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 13:13 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:27 -0700
Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-01 10:00 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 10:29 +0000
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-01 16:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 15:53 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 16:37 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-04 16:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 20:38 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:52 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:00 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 03:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:48 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 20:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:03 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-05 13:09 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:38 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:24 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:28 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:25 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 19:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:47 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-06 16:11 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:50 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 19:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 22:38 -0400
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:06 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:04 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:27 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 20:24 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:30 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:03 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:11 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:02 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 07:35 +1200
Re: IEEE: C is the first programming language "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 16:00 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 08:07 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-08 21:22 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:08 +0200
Re: IEEE: C is the first programming language jameskuyper@verizon.net - 2016-08-08 13:39 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:54 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:50 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 15:19 +0200
Re: IEEE: C is the first programming language already5chosen@yahoo.com - 2016-08-09 09:14 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:22 +0200
Re: IEEE: C is the first programming language James Kuyper <jameskuyper@verizon.net> - 2016-08-09 11:12 -0400
Re: IEEE: C is the first programming language cross@spitfire.i.gajendra.net (Dan Cross) - 2016-08-09 15:25 +0000
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:50 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:44 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 17:38 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 20:06 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:57 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:15 +0200
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-08-08 11:57 +0100
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 23:04 +1200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 15:20 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:27 -0400
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:21 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 17:33 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:35 -0400
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-08-05 14:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 14:37 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 13:53 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:09 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:08 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:34 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:37 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:18 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:31 +0200
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 03:55 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 08:28 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 09:44 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 10:13 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 07:51 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:39 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:27 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 08:38 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:40 -0400
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 21:27 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 00:19 +0200
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 11:49 +0200
Re: IEEE: C is the first programming language raltbos@xs4all.nl (Richard Bos) - 2016-07-28 10:01 +0000
Re: IEEE: C is the first programming language Les Cargill <lcargill99@comcast.com> - 2016-07-28 01:57 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:27 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 09:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 09:39 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 11:56 -0700
Re: IEEE: C is the first programming language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-07-28 15:19 -0400
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:25 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:37 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:21 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 17:17 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 14:17 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 18:43 +0200
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 18:58 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 21:46 +0200
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-01 16:37 +1200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 07:20 -0700
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-29 08:36 -0600 |
| Message-ID | <1br3acse8u.fsf@pfeifferfamily.net> |
| In reply to | #91308 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
> <snip>
>> Seems an obvious optimisation to me. /Clever/ would have been to turn
>> the "printf("c = %u\n", c);" into "puts("c = 9\n");".
>
> You mean puts("c = 9"); (puts adds a newline).
>
> <snip>
Or fputs("c = 9\n", stdout);
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 05:32 -0700 |
| Message-ID | <cce1320f-2bd3-479a-b36d-eaf75764d42c@googlegroups.com> |
| In reply to | #91306 |
On Friday, July 29, 2016 at 6:08:47 AM UTC-4, David Brown wrote:
> On 29/07/16 03:27, Rick C. Hodgin wrote:
> > On Thursday, July 28, 2016 at 7:14:33 PM UTC-4, David Brown wrote:
> >> On 28/07/16 14:24, Rick C. Hodgin wrote:
> >>> On Thursday, July 28, 2016 at 8:03:50 AM UTC-4, David Brown wrote:
> >>>> On 28/07/16 03:03, Rick C. Hodgin wrote:
> >>>>> On Wednesday, July 27, 2016 at 8:20:42 PM UTC-4, supe...@casperkitty.com wrote:
> >>>>>> On many historical or embedded compilers, if one has a pointer to an array
> >>>>>> of uint8_t which is known to be 32-bit aligned, one can cast the pointer
> >>>>>> to uint32_t* and then process elements four at a time and achieve a 4x
> >>>>>> speed boost; on platforms which support uint64_t, if the array is known to
> >>>>>> be 64-bit aligned, casting to uint64_t* and processing elements eight at a
> >>>>>> time may offer an additional speed boost.
> >>>>>>
> >>>>>> Such code is not supported by gcc, however,
> >>>>>
> >>>>> How is this not supported by gcc? Or any C compiler through the cast?
> >>>>
> >>>> What he means is that in C, casting a uint16_t pointer to a uint32_t
> >>>> pointer and using that to access the data is undefined behaviour
> >>>> (assuming uint16_t is not the same type as unsigned char). For some
> >>>> reason, known only to himself, Supercat believes that older C standards
> >>>> (pre C89, I think) /did/ allow this sort of thing. He also believes
> >>>> that many older compilers and embedded compilers also allow it.
> >>>
> >>> I can see that being a constraint in the case of a single local variable
> >>> being accessed, but if you have an array of uint16_t quantities that
> >>> you're trying to access using the wider 32-bit or 64-bit pointers, then
> >>> unless the compiler is doing some really funky internal alignment of
> >>> data, it should be accessible through the larger pointer.
> >>>
> >>> The only case
> >>> I can see where it would generate undefined behavior (apart from strictly
> >>> standard-dictated reasons, which may be the only consideration at work
> >>> here, and if so I withdraw my entire comment) would be in a case like
> >>> this:
> >>>
> >>> uint16_t a;
> >>> float b;
> >>> uint32_t* p;
> >>>
> >>> p = &a;
> >>> *p = 5; // What would happen here would be undefined
> >>>
> >>> In most 32-bit and later compilers I can see this actually working
> >>> because unless the items are packed, they will typically align to
> >>> the largest natural size on the stack. But, in other cases, it
> >>> would fail.
> >>
> >> In many cases, this will fail horribly. You have no guarantee at all
> >> that there is padding after "a" to give you the 32 bits of space. One
> >> obvious case would be if this code were preceded by "uint16_t x;" where
> >> the "x" is on the 4-byte boundary. Then there would be no padding
> >> before "b". But more generally, the compiler can re-arrange the order
> >> of the variables - some compilers do that, precisely to eliminate
> >> padding and generate more efficient code.
> >
> > I would agree that they do that in global memory spaces, but local
> > variables are typically on the stack, and it is ill-advised to have
> > non-aligned accesses on the stack as it is heavily optimized for
> > aligned accesses.
> >
>
> I don't mean that a compiler would re-arrange global variables to make
> them misaligned - I mean it could re-arrange them to make them aligned
> /and/ save space.
I don't think compilers would do that when speed is a factor. The default
member alignment on Microsoft's compilers is 8 bytes, which I think is
ridiculous. But, there it is. I set all of my projects to use 1-byte
alignment because I do care about space, and performance is not a great
concern of mine. I'm already coding in C/C++. It's almost always fast
enough without the extra optimizations.
> So if you write this:
>
> uint16_t a;
> uint8_t b;
> uint32_t c;
> uint8_t d;
> uint64_t e;
>
> Then rather than generating this with 4 bytes wasted space:
>
> (assume 8-byte alignement)
> a: 2 bytes
> b: 1 byte
> padding 1 byte
> c: 4 bytes
> d: 1 byte
> padding 3 bytes
> e: 8 bytes
>
> the compiler might generate:
>
> (assume 8-byte alignement)
> e: 8 bytes
> c: 4 bytes
> a: 2 bytes
> b: 1 byte
> d: 1 byte
I think compilers would do this if you said to pack your data. Otherwise
it would rearrange them so the are aligned on common boundaries which,
on 32-bit machines, will be at least 4-byte aligned.
I see that in all local variables in the compilers I use (x86-based
machines mostly). I rarely see references to local variables that are
not directly aligned. The only times I can directly recall are in packed
structures.
But, I do realize the compiler can do that. I just don't typically see
it done, so it's something I would assume and then, when something didn't
work, go and examine why. I also look forward to CAlive, and it will
align them in that way, except where an override is given to pack local
data.
> Local variables are either on the stack, in registers, or disappear due
> to optimisations. A good compiler will often do a lot of reordering of
> local variables on a stack - but I certainly agree that they will be
> aligned optimally for the platform.
There are sometimes additional constraints in source code which could
override best optimization and/or alignment practices, such as requiring
that the data be packed. But, within those constraints, they will be
aligned optimally for the platform.
> > In a test just now in Microsoft's C compiler, this code:
> > #include "stdlib.h"
> > #include "stdio.h"
> >
> > typedef unsigned short uint16_t;
> > typedef unsigned long uint32_t;
> >
> > int main (int argc, char* argv[])
> > {
> > uint16_t a;
> > uint16_t b;
> > uint32_t c;
> > uint16_t* p;
> >
> > printf("a = 0x%x\nb = 0x%x\n", (uint32_t)&a, (uint32_t)&b);
> >
> > a = 5;
> > b = 4;
> > c = (uint32_t)a + (uint32_t)b;
> > printf("c = %u\n", c);
> > return(0);
> > }
> >
> > Produced this access on the stack and code in a Debug build (unoptimized):
> > a = 0x12ff60
> > b = 0x12ff54
> > c = 9
> >
> > // a = 5;
> > 004113DD mov eax,5
> > 004113E2 mov word ptr [ebp-8],ax // 4-byte aligned
> > // b = 4;
> > 004113E6 mov eax,4
> > 004113EB mov word ptr [ebp-14h],ax // 4-byte aligned
> > // c = (uint32_t)a + (uint32_t)b;
> > 004113EF movzx eax,word ptr [ebp-8]
> > 004113F3 movzx ecx,word ptr [ebp-14h]
> > 004113F7 add eax,ecx
> > 004113F9 mov dword ptr [ebp-20h],eax // 4-byte aligned
> >
> > And this access on the stack and code in a Release build (optimized):
> > a = 0x12ff7c
> > b = 0x12ff78
> > c = 9
> >
> > // a = 5;
> > // b = 4;
> > // c = (uint32_t)a + (uint32_t)b;
> > // printf("c = %u\n", c);
> > 0040101B push 9
> > 0040101D push 402108h
> > 00401022 mov dword ptr [esp+18h],5
> > 0040102A mov dword ptr [esp+1Ch],4
> > 00401032 call esi
> >
> > Ugh! Clever bugger. :-)
>
> Seems an obvious optimisation to me. /Clever/ would have been to turn
> the "printf("c = %u\n", c);" into "puts("c = 9\n");".
I had that thought. Actually my thought was that I think GCC would've
done that. But, I didn't want to test it.
Microsoft's compilers are not the best in optimization, but they are
adequate. I sometimes think optimization is too overrated. How fast
does an algorithm which asks the user to type in the patient's data
and click the save button really need to be? :-)
> >> Supercat certainly makes some good points about code that looks like it
> >> is valid, but has surprising undefined behaviour. But he makes
> >> inaccurate, or downright incorrect, points about how he thinks the
> >> standards used to be, his belief that all compilers used to behave in a
> >> certain fashion, and his belief that modern compiler developers are
> >> maliciously unhelpful regarding undefined behaviour.
> >
> > I would suggest he probably has old compilers he tests things in to
> > determine their functionality. I still have Microsoft's C 6.1 compiler
> > from the early 1990s. I use it still on some code because I wrote it
> > for that compiler back then.
>
> Ah, it is certainly true that for many old compilers, there was no
> type-based aliasing analysis and you could cast between uint16_t* and
> uint32_t* pointers at will and get the "expected" code. So no testing
> is needed.
>
> But it was /never/ true that this was guaranteed by the standards, I
> have never seen it in documented (though I haven't read /all/ compiler
> manuals!), and even long ago there were some compilers that had rather
> sophisticated optimisations that may have taken advantage of type-based
> alias analysis.
I think that most C compilers from that 80s and 90s era did not rely upon
the standards entirely. In fact, I think they often considered the
standard to be too restrictive, or confining, and thereby ignored some
features of it for the sake of benefiting the target platform.
Of course, my experience is limited almost entirely to x86 with some ARM
code. So, my "worldview" is narrow in this regard.
> So I won't disagree with claims of "my old compiler did this...". I
> merely disagree with extending that to "/all/ old compilers did this..."
> or "the old C standards said this...".
I don't know about the standard. I continue to learn more and more about
it here and there and grow both more and more impressed, and also more and
more put off by it (or parts of it I should say).
I may get to the end of my CAlive journey and realize I could've saved
myself years of trouble by just learning it from the beginning. :-)
Nonetheless, it is my offering unto the Lord, and unto all of man. It's
a large part of why it has the name "alive" in it (because He lives)...
> >> But if we all agreed, what point would there be in a discussion group? :-)
> > Agreed. [pause ... realization] D'oh!
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-29 14:42 +0100 |
| Message-ID | <nnfmg2$8j7$1@dont-email.me> |
| In reply to | #91310 |
On 29/07/2016 13:32, Rick C. Hodgin wrote: > On Friday, July 29, 2016 at 6:08:47 AM UTC-4, David Brown wrote: > Microsoft's compilers are not the best in optimization, but they are > adequate. I sometimes think optimization is too overrated. How fast > does an algorithm which asks the user to type in the patient's data > and click the save button really need to be? :-) Exactly. In real applications the overall difference made by super-optimisation can be small. You don't even need to bring user-interaction into it. My latest compiler-related project, which is near 100% self-contained computation, is only 28% faster when compiled with gcc -O3 compared with gcc -O0. (And gcc -O3 is only 17% faster, in the same test, than my own toy compiler with no optimiser to speak of.**) Sometimes there is a bottle-neck is some critical function or in a library function, and the you do what you can: put that into a separate module, use the fastest compilers etc. But for most of the code of a project, it is not critical. (I used to fix such bottlenecks by writing the critical code in in-line assembly.) [**Toy compiler with x64 target compared with gcc with -m64. gcc -m32 -O3 performs better (28% faster than my toy compiler, and 33% faster when gcc -m32 -O3 is compared to gcc -m32 -O0). C code involved is machine-generated and no special tweaks, attributes or compile-options are used other than -O3] -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 06:59 -0700 |
| Message-ID | <2893cf63-1cb0-4fe1-bed1-552ae492e924@googlegroups.com> |
| In reply to | #91311 |
On Friday, July 29, 2016 at 9:42:34 AM UTC-4, Bart wrote: > On 29/07/2016 13:32, Rick C. Hodgin wrote: > > On Friday, July 29, 2016 at 6:08:47 AM UTC-4, David Brown wrote: > > > Microsoft's compilers are not the best in optimization, but they are > > adequate. I sometimes think optimization is too overrated. How fast > > does an algorithm which asks the user to type in the patient's data > > and click the save button really need to be? :-) > > Exactly. > > In real applications the overall difference made by super-optimisation > can be small. > > You don't even need to bring user-interaction into it. My latest > compiler-related project, which is near 100% self-contained computation, > is only 28% faster when compiled with gcc -O3 compared with gcc -O0. > > (And gcc -O3 is only 17% faster, in the same test, than my own toy > compiler with no optimiser to speak of.**) > > Sometimes there is a bottle-neck is some critical function or in a > library function, and the you do what you can: put that into a separate > module, use the fastest compilers etc. But for most of the code of a > project, it is not critical. > > (I used to fix such bottlenecks by writing the critical code in in-line > assembly.) > > [**Toy compiler with x64 target compared with gcc with -m64. gcc -m32 > -O3 performs better (28% faster than my toy compiler, and 33% faster > when gcc -m32 -O3 is compared to gcc -m32 -O0). > > C code involved is machine-generated and no special tweaks, attributes > or compile-options are used other than -O3] For a long time Microsoft's "free" products would not produce optimized code, but only unoptimized. I used to think, "Really? You've already designed the algorithm. It's working. You're really going to hoard it from people unless they pony up more cash?" Truly evil (http://biblehub.com/kjv/1_timothy/6-10.htm). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-29 16:08 +0100 |
| Message-ID | <nnfrhk$r81$1@dont-email.me> |
| In reply to | #91313 |
On 29/07/2016 14:59, Rick C. Hodgin wrote: > For a long time Microsoft's "free" products would not produce optimized > code, but only unoptimized. > > I used to think, "Really? You've already designed the algorithm. It's > working. You're really going to hoard it from people unless they pony > up more cash?" I can't see anything wrong with that actually. Plenty of products which have a free version but you have pay if you want a higher spec one. Or cheap products with a more expensive, more capable version. Often, in the case of software, it will be the same product but the higher features are disabled. Or is this only because it's Microsoft? The people who work there still have to eat. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-29 09:16 -0700 |
| Message-ID | <54085e4c-dc34-4cf2-9719-28b7437cdced@googlegroups.com> |
| In reply to | #91318 |
On Friday, July 29, 2016 at 4:08:45 PM UTC+1, Bart wrote: > On 29/07/2016 14:59, Rick C. Hodgin wrote: > > > For a long time Microsoft's "free" products would not produce optimized > > code, but only unoptimized. > > > > I used to think, "Really? You've already designed the algorithm. It's > > working. You're really going to hoard it from people unless they pony > > up more cash?" > > I can't see anything wrong with that actually. Plenty of products which > have a free version but you have pay if you want a higher spec one. > > Or cheap products with a more expensive, more capable version. Often, in > the case of software, it will be the same product but the higher > features are disabled. > > Or is this only because it's Microsoft? The people who work there still > have to eat. > Sounds reasonable on the face of it. In fact the compiler and associated bits and pieces is an essential tool for getting software up and running on Windows. Microsoft's business model is completely dependent on a raft of third party applications, which customers need to buy the operating system for if they wish to run. An expensive compiler is just a routine bill for an established software development house, but for a bedroom programmer, the prices are prohibitive. So Microsoft squeezes out talent coming into Windows development.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 09:21 -0700 |
| Message-ID | <d5ab15b6-2f4e-43f8-acd8-9639c6420366@googlegroups.com> |
| In reply to | #91318 |
On Friday, July 29, 2016 at 11:08:45 AM UTC-4, Bart wrote:
> On 29/07/2016 14:59, Rick C. Hodgin wrote:
>
> > For a long time Microsoft's "free" products would not produce optimized
> > code, but only unoptimized.
> >
> > I used to think, "Really? You've already designed the algorithm. It's
> > working. You're really going to hoard it from people unless they pony
> > up more cash?"
>
> I can't see anything wrong with that actually. Plenty of products which
> have a free version but you have pay if you want a higher spec one.
Of course it is in all ways wrong, Bart. We are human beings on this
planet together. We have each been given gifts and opportunities by God
so as to influence the people around us. We are not supposed to do it
for money, but to help each other. Satan teaches "money ahead of
rightness."
I remember a song from back in the day: "God Money" I think was its
title, by Trent Reznor / NiN. "God Money, I'll do anything for you.
God Money, just tell me what you want me to. God Money let's go
dancing on the backs of the bruised. God Money's not one to choose."
So true.
> Or cheap products with a more expensive, more capable version. Often, in
> the case of software, it will be the same product but the higher
> features are disabled.
EXACTLY! It is flatly criminal to completely integrate features into
a product, and then hobble them so as to squeeze out more money from
people to get the fully-featured version. YOU'VE ALREADY BUILT IT!!!
It's been coded, tested, debugged. Why hobble it? For money? Really!?
Such things are in all ways wrong, and they are the result of Satan's
influence in this world, putting self and self-interests ahead of the
needs of others, when there's no reason to do it other than completely
selfish needs.
I remember a question asked by Bud Fox to Gordon Gecko: "How many
yachts can you water ski behind? When is it enough?"
Microsoft has been found guilty in multiple courts of law for anti-
competitive practices. Their latest Windows 8 and Windows 10 upgrades
are draconian in the amount of information they capture about people,
unless you dig in pretty deep and turn off all the automatically-on-
from-the-factory features Microsoft setup.
> Or is this only because it's Microsoft? The people who work there still
> have to eat.
They did eat. All of them. While they were writing the FULL version
of the software. They then continued to eat. All of them. While they
were hobbling the FULL version to produce the LESSER versions.
It's insanity that's accepted because "that's just the way the world
operates, mister."
NO! The world may operate that way, but the world has it wrong. And
I will not participate in that system in any way shape or form beyond
the absolute minimum necessities of getting up and going from where I'm
forced to start here in this world.
You ought to listen to my commentary from 30 minutes on in this video,
which explains why I'm working on the Visual FreePro Project, which then
later turned into the Village Freedom Project:
http://www.visual-freepro.org/videos/2012_12_08__01_vvmmc__and_vfrps_relationship_to_christianity.ogv
If you can't view it, use VLC (www.videolan.org).
There is a purpose to our lives here, and it's not to do business with
one another for profit. It's to help one another become all that we
were created to be. To give the best of ourselves to others expecting
nothing in return, and then relying upon God Himself to provide for our
true needs, and not just our personal wants.
This world brings forth abundantly to feed everybody, yet all of these
countries around the world have people starving. Even a modern entity
like Venezuela. They say on the news reports "It's not economically
feasible for countries to do business with Venezuela," so the people
are starving and there is such unrest.
It's criminal when we have tractor factories able to produce machines
which can plant and harvest food enough for everybody. And when there
are money barriers at work, it is the most fully entrenched form of
1 Timothy 6:10 (http://biblehub.com/kjv/1_timothy/6-10.htm) there can
be. People are being harmed because money needs (a non-breathing, non-
living thing with no soul, a form which the Bible records the love of
is the root of ALL evil) are being placed ahead of people needs.
-----
It won't be like this in eternity. And for all who follow after Jesus
Christ here upon this Earth, it is not to be like this for them either.
We are all here to shoulder one another's burdens, because together we
are strong, but in isolation we are weak. We should be looking after
one another, seeing where we can help another. It fills you on the
inside in ways nothing else can, because it's giving, and that giving
is from God as He is the true giver and the source of all giving.
No, Bart, it is wrong. It is the epitome of evil. It is why I started
the Liberty Software Foundation and what later became the Village Freedom
Project, rather than working for the Free Software Foundation and the
GNU Project.
It's a conscious effort given in this world with a focus on God, rather
than on other things.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-29 17:55 +0100 |
| Message-ID | <nng1qc$i7l$1@dont-email.me> |
| In reply to | #91324 |
On 29/07/2016 17:21, Rick C. Hodgin wrote: > On Friday, July 29, 2016 at 11:08:45 AM UTC-4, Bart wrote: >> Or cheap products with a more expensive, more capable version. Often, in >> the case of software, it will be the same product but the higher >> features are disabled. > > EXACTLY! It is flatly criminal to completely integrate features into > a product, and then hobble them so as to squeeze out more money from > people to get the fully-featured version. YOU'VE ALREADY BUILT IT!!! > It's been coded, tested, debugged. Why hobble it? For money? Really!? You've got it back to front. Someone produces something and sells at a fair price to cover the costs of development, on-going maintenance and support, pay back investors, cover other products that lost money, all the usual things. But then they decide to make available a version for those who can't afford the full price. Either at a much lower price or for free. Now people can benefit who wouldn't have done otherwise. Sometimes, a trial version is available which is a time-limited version of the exact same software. Anyway these days there are hundreds of thousands of free applications, including IDEs, compilers and language development suites. If someone is paying for software, then it is through choice. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 11:00 -0700 |
| Message-ID | <660bfa9c-c434-408c-82ca-351e4137c4d7@googlegroups.com> |
| In reply to | #91329 |
On Friday, July 29, 2016 at 12:55:48 PM UTC-4, Bart wrote:
> On 29/07/2016 17:21, Rick C. Hodgin wrote:
> > On Friday, July 29, 2016 at 11:08:45 AM UTC-4, Bart wrote:
>
> >> Or cheap products with a more expensive, more capable version. Often, in
> >> the case of software, it will be the same product but the higher
> >> features are disabled.
> >
> > EXACTLY! It is flatly criminal to completely integrate features into
> > a product, and then hobble them so as to squeeze out more money from
> > people to get the fully-featured version. YOU'VE ALREADY BUILT IT!!!
> > It's been coded, tested, debugged. Why hobble it? For money? Really!?
>
> You've got it back to front.
>
> Someone produces something and sells at a fair price to cover the costs
> of development, on-going maintenance and support, pay back investors,
> cover other products that lost money, all the usual things.
>
> But then they decide to make available a version for those who can't
> afford the full price. Either at a much lower price or for free.
>
> Now people can benefit who wouldn't have done otherwise.
>
> Sometimes, a trial version is available which is a time-limited version
> of the exact same software.
>
> Anyway these days there are hundreds of thousands of free applications,
> including IDEs, compilers and language development suites. If someone is
> paying for software, then it is through choice.
No, Bart, you have it back to front.
The full product should be released to everybody. If you want to disable
certain features, they should be selectable via some settings which are
then released into the released version allow me to choose, if I desire,
to turn off some features I don't want.
If a product is produced that's capable of being replicated to all without
consuming the first ... give it to everybody. Don't even sell it. It is
a gift given to us by God in that way, and it is a preview of what Heaven
will be like (full use, yet without consumption).
It's the only thing technology-related thing given to mankind that we can
both have and use and share with everybody without ever losing anything
we originally had in the product. Yet it is man who has erected otherwise
non-existent invisible fortress barriers around these forms of digital
content, so as to drag them down into the mucky realm of tangible products
which require ongoing labor and materials to create, inventing concepts
like intellectual property and copyrights and idea patents.
It is the enemy of this world taking this incredible gift given unto all
of mankind, the ability to ongoingly create any degree of content and share
it world-wide with everybody for no more expense than they would've incurred
in the first place to possess and utilize the equipment it requires. And
what does sinful man do? Comes along and hobbles that gift tremendously
under the weight of money-focused rules.
No, Bart! It is you who has it backwards. You are thinking like the
world, and not as one seeking after the Kingdom of God.
Love is the only exception to the rule, by the way, because with love you
can have and use and share love, and not only continually possess it, but
it actually continues to grow so that what you end up with in the end is
even more love than you started out with. The original love is there, it's
just growing, because love is truly alive, because Jesus Christ is alive,
and Jesus Christ is love.
The ways of commerce in this world will not persist forever. In fact, in
one climactic event in Revelation the entire economy of this fallen world
is destroyed in one hour:
http://biblehub.com/kjv/revelation/18.htm
1 And after these things I saw another angel come down from heaven,
having great power; and the earth was lightened with his glory.
2 And he cried mightily with a strong voice, saying, Babylon the great
is fallen, is fallen, and is become the habitation of devils, and the
hold of every foul spirit, and a cage of every unclean and hateful
bird.
9 And the kings of the earth, who have committed fornication and lived
deliciously with her, shall bewail her, and lament for her, when they
shall see the smoke of her burning,
10 Standing afar off for the fear of her torment, saying, Alas, alas,
that great city Babylon, that mighty city! for in one hour is thy
judgment come.
It's time to get right with God, people. Only His Kingdom will endure.
And the time of this worldly kingdom in power today is almost up.
http://biblehub.com/kjv/revelation/22-7.htm
"Behold, I come quickly: blessed is he that keepeth the sayings of the
prophecy of this book."
Tick tock. Tick tock. Tick tock.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 11:48 -0700 |
| Message-ID | <ced31393-80a8-4c88-b7c2-e34a835957b1@googlegroups.com> |
| In reply to | #91334 |
On Friday, July 29, 2016 at 2:00:17 PM UTC-4, Rick C. Hodgin wrote:
> The ways of commerce in this world will not persist forever. In fact, in
> one climactic event in Revelation the entire economy of this fallen world
> is destroyed in one hour:
>
> http://biblehub.com/kjv/revelation/18.htm
>
> 1 And after these things I saw another angel come down from heaven,
> having great power; and the earth was lightened with his glory.
>
> 2 And he cried mightily with a strong voice, saying, Babylon the great
> is fallen, is fallen, and is become the habitation of devils, and the
> hold of every foul spirit, and a cage of every unclean and hateful
> bird.
>
> 9 And the kings of the earth, who have committed fornication and lived
> deliciously with her, shall bewail her, and lament for her, when they
> shall see the smoke of her burning,
>
> 10 Standing afar off for the fear of her torment, saying, Alas, alas,
> that great city Babylon, that mighty city! for in one hour is thy
> judgment come.
>
> It's time to get right with God, people. Only His Kingdom will endure.
> And the time of this worldly kingdom in power today is almost up.
>
> http://biblehub.com/kjv/revelation/22-7.htm
> "Behold, I come quickly: blessed is he that keepeth the sayings of the
> prophecy of this book."
>
> Tick tock. Tick tock. Tick tock.
Jesus Christ is willing to give everyone world-wide full forgiveness for
your sin. He's willing to restore you to the Kingdom of Heaven, and all
that it means to be a child of God made in the very image of God. The
Bible records that we will be co-heirs with Christ, meaning what He
receives, we also will receive ... and what is He receiving? Everything!
This is the greatest opportunity any of us have ever been given, or will
ever be given. All of us have sinned. And all of us CAN be forgiven if
we will humble ourselves, acknowledge our sin, and ask forgiveness.
Eternity is LITERALLY yours for the taking. Do not pass Him by, because
He is the only way to enter into Heaven, and He's giving it away for free.
You don't have to do special things to receive it, just come to Him and
ask Him to be forgiven. No mountains to climb. No cleaning up your own
life first. Come as you are, today, right now, and be saved.
Here is what He offers: rest for your soul.
http://www.libsf.org/misc/love.html
Jesus Will Always Receive You
Matthew 11:28-30 King James Version
28 Come unto me, all ye that labour and are heavy laden, and I will
give you rest.
29 Take my yoke upon you, and learn of me; for I am meek and lowly
in heart: and ye shall find rest unto your souls.
30 For my yoke is easy, and my burden is light.
You'll never get a better offer: Eternal life for the asking of
forgiveness for the sins you know you've committed.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-29 21:12 +0100 |
| Message-ID | <nngdc6$tek$1@dont-email.me> |
| In reply to | #91334 |
On 29/07/2016 19:00, Rick C. Hodgin wrote: > On Friday, July 29, 2016 at 12:55:48 PM UTC-4, Bart wrote: > It's the only thing technology-related thing given to mankind that we can > both have and use and share with everybody without ever losing anything > we originally had in the product. Yet it is man who has erected otherwise > non-existent invisible fortress barriers around these forms of digital > content, so as to drag them down into the mucky realm of tangible products > which require ongoing labor and materials to create, inventing concepts > like intellectual property and copyrights and idea patents. Do you have a programming job? If so, do you get paid for it? Since code can be replicated for nothing, what would you think about doing the coding for nothing? Or suppose your clients decide to download a free version of whatever it is you do, made available by someone who has already covered his costs and thinks as you do, that everyone should benefit. Now you and your family will starve. Good work! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-29 19:39 -0700 |
| Message-ID | <37c4b82a-a452-4539-826b-03e4077c93ac@googlegroups.com> |
| In reply to | #91337 |
On Friday, July 29, 2016 at 4:13:11 PM UTC-4, Bart wrote:
> On 29/07/2016 19:00, Rick C. Hodgin wrote:
> > On Friday, July 29, 2016 at 12:55:48 PM UTC-4, Bart wrote:
>
> > It's the only thing technology-related thing given to mankind that we can
> > both have and use and share with everybody without ever losing anything
> > we originally had in the product. Yet it is man who has erected otherwise
> > non-existent invisible fortress barriers around these forms of digital
> > content, so as to drag them down into the mucky realm of tangible products
> > which require ongoing labor and materials to create, inventing concepts
> > like intellectual property and copyrights and idea patents.
>
> Do you have a programming job? If so, do you get paid for it?
>
> Since code can be replicated for nothing, what would you think about
> doing the coding for nothing?
I write all of my personal code and give it away under a Public Domain
license. For my life and living and substance in this world, I have a
job where I get paid for my labor. I do not create something of grand
stature, and then continue to not conduct labor for my ongoing wage,
but rather I work for what I'm paid. This is the Biblical position,
that we are paid for our labor, but not for prior work:
http://biblehub.com/kjv/genesis/3-19.htm
"In the sweat of thy face shalt thou eat bread, till thou return
unto the ground; for out of it wast thou taken: for dust thou art,
and unto dust shalt thou return."
We are to work throughout our life.
> Or suppose your clients decide to download a free version of whatever it
> is you do, made available by someone who has already covered his costs
> and thinks as you do, that everyone should benefit.
Listen to the video, Bart. It will teach you the philosophy that today
you are not understanding, and why you cannot reconcile the position of
having a job for a wage, and creating something that then becomes a
completed thing that HAS BEEN developed:
It begins around 30 minutes:
http://www.visual-freepro.org/videos/2012_12_08__01_vvmmc__and_vfrps_relationship_to_christianity.ogv
If you can't view the video, use VLC (www.videolan.org).
> Now you and your family will starve. Good work!
The work we do, our labor, pays for our wages in this world. Be it
toil in a garden and on a farm for no pay, but the needs of a person,
or be it in a job for pay where we exchange our money for those things
we need, exchanging our labor in other areas valuable to society for
things society gives us for our labor in return.
We are not to sit atop prior work and continue to make money off that
product, but are to only receive pay for our ongoing labor.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-29 14:56 -0700 |
| Message-ID | <af04b115-b7a0-4484-b8e7-085ccbb94e0d@googlegroups.com> |
| In reply to | #91334 |
On Friday, July 29, 2016 at 1:00:17 PM UTC-5, Rick C. Hodgin wrote: > On Friday, July 29, 2016 at 12:55:48 PM UTC-4, Bart wrote: > > On 29/07/2016 17:21, Rick C. Hodgin wrote: > > > On Friday, July 29, 2016 at 11:08:45 AM UTC-4, Bart wrote: > > > > >> Or cheap products with a more expensive, more capable version. Often, in > > >> the case of software, it will be the same product but the higher > > >> features are disabled. > > > > > > EXACTLY! It is flatly criminal to completely integrate features into > > > a product, and then hobble them so as to squeeze out more money from > > > people to get the fully-featured version. YOU'VE ALREADY BUILT IT!!! > > > It's been coded, tested, debugged. Why hobble it? For money? Really!? > > > > You've got it back to front. > > > > Someone produces something and sells at a fair price to cover the costs > > of development, on-going maintenance and support, pay back investors, > > cover other products that lost money, all the usual things. > > > > But then they decide to make available a version for those who can't > > afford the full price. Either at a much lower price or for free. > > > > Now people can benefit who wouldn't have done otherwise. > > > > Sometimes, a trial version is available which is a time-limited version > > of the exact same software. > > > > Anyway these days there are hundreds of thousands of free applications, > > including IDEs, compilers and language development suites. If someone is > > paying for software, then it is through choice. > > No, Bart, you have it back to front. > > The full product should be released to everybody. If you want to disable > certain features, they should be selectable via some settings which are > then released into the released version allow me to choose, if I desire, > to turn off some features I don't want. > > If a product is produced that's capable of being replicated to all without > consuming the first ... give it to everybody. Don't even sell it. It is > a gift given to us by God in that way, and it is a preview of what Heaven > will be like (full use, yet without consumption). > I partly agree. Not really as a recommendation for others, but solely as a personal choice. In the broadest outline of the xpost project, the sum of the parts shall be the cross-product of a literate program and a quine. The "action" of the product is to produce pdfs so by feeding its source through itself it results in a lavishly-illustrated self- elucidating cryptonomicon. Also available handsomely-bound for $$s. http://web.archive.org/web/20160404161635/https://code.google.com/p/xpost/wiki/WhatIsXpost
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 08:54 -0700 |
| Message-ID | <070c0a70-2bcb-480c-9cc5-48daa1ce6c5b@googlegroups.com> |
| In reply to | #91310 |
On Friday, July 29, 2016 at 7:32:11 AM UTC-5, Rick C. Hodgin wrote:
> I think that most C compilers from that 80s and 90s era did not rely upon
> the standards entirely. In fact, I think they often considered the
> standard to be too restrictive, or confining, and thereby ignored some
> features of it for the sake of benefiting the target platform.
Prior to 1989, many platforms allowed compilers to very easily and
cheaply offer features and guarantees beyond those which would
eventually be mandated by the Standard, but many such features and
guarantees could not be readily supported on all platforms. Further,
many tasks could be performed much more efficiently on implementations
that offered such features and guarantees than on those which could
not.
Any single language specification, no matter how it was written, would
need to accept one of two problems:
1. It would not be possible for an implementation compliant with the
new standard to process existing programs as efficiently as an
existing implementation on the same platform (if at all).
2. Programmers would need to use features and guarantees beyond those
mandated by the Standard in order to write code for certain platforms
that could work as efficiently as existing code on those platforms
(or--in some cases--even work at all).
When writing the Standard, the authors perceived that #1 would impair
compiler writers than #2 would impair programmers (since before 1989,
any program that did *anything* would be reliant upon compiler writers
supporting things without a standard-imposed mandate). The Standard
may say that given:
unsigned int mul(unsigned short x, unsigned short y} { return x*y; }
a compiler for a 32-bit platform would be entitled to do anything it
likes when given the statement "unsigned int v=mul(50000,50000);", but
a compiler writer who decides that the most sensible behavior is to
have the function set v to 2500000000U would not be "ignoring the
standard", but merely exercising judgment permitted thereby.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-01 10:30 +0200 |
| Message-ID | <nnn1ae$src$1@dont-email.me> |
| In reply to | #91310 |
On 29/07/16 14:32, Rick C. Hodgin wrote: > On Friday, July 29, 2016 at 6:08:47 AM UTC-4, David Brown wrote: >> On 29/07/16 03:27, Rick C. Hodgin wrote: >>> On Thursday, July 28, 2016 at 7:14:33 PM UTC-4, David Brown wrote: <snip> >> I don't mean that a compiler would re-arrange global variables to make >> them misaligned - I mean it could re-arrange them to make them aligned >> /and/ save space. > > I don't think compilers would do that when speed is a factor. The default > member alignment on Microsoft's compilers is 8 bytes, which I think is > ridiculous. But, there it is. I set all of my projects to use 1-byte > alignment because I do care about space, and performance is not a great > concern of mine. I'm already coding in C/C++. It's almost always fast > enough without the extra optimizations. I was talking specifically about global data (or, more accurately, data with program lifetime - the scope and access of the data does not matter). Compilers may use bigger alignment for items on the stack than for statically allocated data with program lifetime. Since local data only exists for a short time, and is mostly in registers, it can make more sense to make it match the width of the register (typically 4 or even 8 bytes) rather than its true size. However, this could vary a good deal from compiler to compiler, and also depend on optimisation levels - without any optimisation enabled, a compiler may take a simple approach such as align all stack variables to 8 byte boundaries. With optimisation, of course, a good many local variables never appear on the stack at all. Setting alignment of data to 1 byte rather than natural alignment for the target will almost certainly be negligible in terms of data space (you might save a few hundred bytes total ram in a large program), but can easily be very significant in performance. When you have got a fancy sports car, you don't keep it in first gear and claim it is fast enough because it is a sports car. Using a "fast" language like C, then limiting it by avoiding all compiler optimisations, and then cripple it with intentional pessimations such as changing the alignment of data. With enough effort, even C can be made slower than Java, C#, Python, etc. > >> So if you write this: >> >> uint16_t a; >> uint8_t b; >> uint32_t c; >> uint8_t d; >> uint64_t e; >> >> Then rather than generating this with 4 bytes wasted space: >> >> (assume 8-byte alignement) >> a: 2 bytes >> b: 1 byte >> padding 1 byte >> c: 4 bytes >> d: 1 byte >> padding 3 bytes >> e: 8 bytes >> >> the compiler might generate: >> >> (assume 8-byte alignement) >> e: 8 bytes >> c: 4 bytes >> a: 2 bytes >> b: 1 byte >> d: 1 byte > > I think compilers would do this if you said to pack your data. Otherwise > it would rearrange them so the are aligned on common boundaries which, > on 32-bit machines, will be at least 4-byte aligned. That was rearranged to align them on suitable boundaries. On most targets, the best alignment for objects up to the natural width of the processor is the size of the object. So for a 64-bit cpu for example, you want to align 32-bit "int" on 4 byte boundaries, but there is no benefit in aligning 16-bit "short" more carefully than 2 byte boundaries. > > I see that in all local variables in the compilers I use (x86-based > machines mostly). I rarely see references to local variables that are > not directly aligned. The only times I can directly recall are in packed > structures. Again, I was not talking about local variables. But certainly with locals, the compiler is not going to make the alignment worse than "natural". > > But, I do realize the compiler can do that. I just don't typically see > it done, so it's something I would assume and then, when something didn't > work, go and examine why. I also look forward to CAlive, and it will > align them in that way, except where an override is given to pack local > data. > >> Local variables are either on the stack, in registers, or disappear due >> to optimisations. A good compiler will often do a lot of reordering of >> local variables on a stack - but I certainly agree that they will be >> aligned optimally for the platform. > > There are sometimes additional constraints in source code which could > override best optimization and/or alignment practices, such as requiring > that the data be packed. But, within those constraints, they will be > aligned optimally for the platform. > <snip> > Microsoft's compilers are not the best in optimization, but they are > adequate. I sometimes think optimization is too overrated. How fast > does an algorithm which asks the user to type in the patient's data > and click the save button really need to be? :-) Although I don't use MS's tools at all, my understanding is that their optimisations are pretty good. Certainly optimisation is often overrated - "Premature optimisation is the root of all evil". But the operative word here is "premature". Optimising /appropriately/ is often important. > >>>> Supercat certainly makes some good points about code that looks like it >>>> is valid, but has surprising undefined behaviour. But he makes >>>> inaccurate, or downright incorrect, points about how he thinks the >>>> standards used to be, his belief that all compilers used to behave in a >>>> certain fashion, and his belief that modern compiler developers are >>>> maliciously unhelpful regarding undefined behaviour. >>> >>> I would suggest he probably has old compilers he tests things in to >>> determine their functionality. I still have Microsoft's C 6.1 compiler >>> from the early 1990s. I use it still on some code because I wrote it >>> for that compiler back then. >> >> Ah, it is certainly true that for many old compilers, there was no >> type-based aliasing analysis and you could cast between uint16_t* and >> uint32_t* pointers at will and get the "expected" code. So no testing >> is needed. >> >> But it was /never/ true that this was guaranteed by the standards, I >> have never seen it in documented (though I haven't read /all/ compiler >> manuals!), and even long ago there were some compilers that had rather >> sophisticated optimisations that may have taken advantage of type-based >> alias analysis. > > I think that most C compilers from that 80s and 90s era did not rely upon > the standards entirely. In fact, I think they often considered the > standard to be too restrictive, or confining, and thereby ignored some > features of it for the sake of benefiting the target platform. That is possible - I don't have the experience to confirm or deny it. I hadn't did not really think about standards during the 90's (although I have had occasion to use a 90's era compiler during the past couple of years). > > Of course, my experience is limited almost entirely to x86 with some ARM > code. So, my "worldview" is narrow in this regard. > >> So I won't disagree with claims of "my old compiler did this...". I >> merely disagree with extending that to "/all/ old compilers did this..." >> or "the old C standards said this...". > > I don't know about the standard. I continue to learn more and more about > it here and there and grow both more and more impressed, and also more and > more put off by it (or parts of it I should say). > > I may get to the end of my CAlive journey and realize I could've saved > myself years of trouble by just learning it from the beginning. :-) > Nonetheless, it is my offering unto the Lord, and unto all of man. It's > a large part of why it has the name "alive" in it (because He lives)... > >>>> But if we all agreed, what point would there be in a discussion group? :-) >>> Agreed. [pause ... realization] D'oh! > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 08:13 -0700 |
| Message-ID | <b5c410a1-3a2a-4ea3-b5cd-8283d995bcd7@googlegroups.com> |
| In reply to | #91306 |
On Friday, July 29, 2016 at 5:08:47 AM UTC-5, David Brown wrote:
> But it was /never/ true that this was guaranteed by the standards, I
> have never seen it in documented (though I haven't read /all/ compiler
> manuals!), and even long ago there were some compilers that had rather
> sophisticated optimisations that may have taken advantage of type-based
> alias analysis.
A compliant implementation could mark all non-character types with padding
bits to identify their types, and trap any time an attempt is made to use
a pointer to a non-character type to access anything of any other type.
It would have been silly for the Standard to mandate that implementations
must recognize aliasing in such cases, when an implementation which
recognized aliasing would be allowed to do anything it likes including
pretending to ignore aliasing.
On the other hand, even the authors of the Standard acknowledge an enormous
gap between what is necessary for a compiler to be standards-compliant
versus what is required for a compiler to be useful and of good quality(*).
On implementations with integer types that don't have padding, aliasing can
be useful for some types of code, and an implementation that supports it
can thus be more useful for creating such code than one which does not.
While the authors of the Standard clearly did a very bad job of saying what
they meant with regard to aliasing (no matter *what* they meant, the amount
of confusion it has created proves they said it badly), I think the real
intention was to identify cases where some code might work correctly--and
more efficiently--if compilers ignored aliasing, but the Committee felt
is was important that all compilers recognize it *anyway*. I think they
would have recognized that a compiler for a given platform that recognized
aliasing in more cases that were useful on that platform would be of higher
quality than one which didn't.
(*) I'm not sure they realized *how* big the gap was, but from what I can
tell, one could have a C89-compliant "implementation" that never even
bothered to examine any of the source files. For C99 or C11, one
would probably need a real preprocessor to handle #error directives,
but one could hand-wave away anything else.
Of course, any useful quality implementation must examine source
files and generate code based upon the content thereof (even though
the Standard doesn't actually mandate any such thing). I would
suggest that there are many other things not mandated by the Standard
which good quality implementations should do.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 12:18 -0700 |
| Message-ID | <kfnmvkxmxaq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91319 |
supercat@casperkitty.com writes: > On Friday, July 29, 2016 at 5:08:47 AM UTC-5, David Brown wrote: >> But it was /never/ true that this was guaranteed by the standards, I >> have never seen it in documented (though I haven't read /all/ compiler >> manuals!), and even long ago there were some compilers that had rather >> sophisticated optimisations that may have taken advantage of type-based >> alias analysis. > > A compliant implementation could mark all non-character types with padding > bits to identify their types, and trap any time an attempt is made to use > a pointer to a non-character type to access anything of any other > type. [...] Wrong. By the way, the word is "conforming", not "compliant".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 07:34 -0700 |
| Message-ID | <8629c14d-fa71-426f-b663-b3c30c35bbb5@googlegroups.com> |
| In reply to | #91289 |
On Thursday, July 28, 2016 at 6:14:33 PM UTC-5, David Brown wrote:
> Supercat certainly makes some good points about code that looks like it
> is valid, but has surprising undefined behaviour. But he makes
> inaccurate, or downright incorrect, points about how he thinks the
> standards used to be, his belief that all compilers used to behave in a
> certain fashion, and his belief that modern compiler developers are
> maliciously unhelpful regarding undefined behaviour.
In C89, given [assume "long" and "short" are four bytes and two bytes,
respectively, and assume the malloc() will succeed]:
#include <stdlib.h>
int foo(void)
{
long *lp = malloc(7);
short *sp = (short*)(lp+1);
void *ep = sp+1;
int temp;
*lp = 12345678;
*sp = 12345;
temp = ep > (void*)lp;
free(lp);
return temp;
}
would there be any undefined behavior? If so, where? Since the Standard
says that the comparison in the last line yields Undefined Behavior unless
all pointers being compared identify parts of the same union or aggregate
object, and since I don't think it would be reasonable to say that pointers
to parts of a malloc region cannot be compared, that would suggest that
ep and lp identify parts of the same aggregate or union. Do you disagree?
The two pointers can't possibly be interpreted as identifying different
parts of a "long[]", since there's only room for one "long" in the
allocation and the pointer is completely outside the range of a "long[1]".
The only way I can see of defining the pointers as being part of the same
aggregate object is if they are regarded as being part of a "char[7]",
and the authors of the Standard had intended to allow that storage to be
accessed as other types [the alignment guarantees associated with malloc
would be worthless if the storage could only be accessed using character
types]. Similar issues would arise, btw, if one tried to use memcpy() on
the region, since the behavior of memcpy() is undefined if an array is
accessed past the end of "an object".
Until machines started requiring radical out-of-order execution to achieve
optimal performance, the majority of the optimization benefits that could
be achieved via aliasing rules could be achieved by applying the rule to
objects with a declared type which are accessed both directly via that type
and also via pointers of other non-character types. Given that nothing in
the Standard would prohibit compiler writers from defining #pragma
directives to enable more radical optimizations, nor from providing
command-line options to enable non-compliant aliasing modes, I see no
reason that anyone in 1990 who read the Standard and the rationale should
have expected that a quality compiler would, in the absence of #pragma
directives or command-line options that invoke non-standard modes, expect
anything remotely resembling gcc's current behavior.
You've indicated disagreement with my assessment of the C89 Standard's rules
about aliasing, but I'm curious what flaws you find in my logic.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-29 14:10 -0700 |
| Message-ID | <5adb4372-9798-4076-b74d-08b5e63b91b7@googlegroups.com> |
| In reply to | #91289 |
On Thursday, July 28, 2016 at 6:14:33 PM UTC-5, David Brown wrote:
> ... his belief that all compilers used to behave in a
> certain fashion, and his belief that modern compiler developers are
> maliciously unhelpful regarding undefined behaviour.
There's a difference between obtuseness and malice.
I do not doubt that the authors of gcc honestly think that given something
like [assume 32-bit "int"]:
unsigned mul(unsigned short x, unsigned short y) { return x*y; }
unsigned mul65535(unsigned short x) { return mul(x, 65535); }
a good compiler should ignores any code that would only be relevant if
mul65535() were passed a value greater than 32768, and such behavior should
be considered superior to simply having mul() yield the arithmetically-
correct value in all cases. I would regard such a belief as downright
obtuse, but that does not mean that I doubt the sincerity thereof.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-29 23:36 +0100 |
| Message-ID | <87lh0kxeam.fsf@bsb.me.uk> |
| In reply to | #91338 |
supercat@casperkitty.com writes:
> On Thursday, July 28, 2016 at 6:14:33 PM UTC-5, David Brown wrote:
>> ... his belief that all compilers used to behave in a
>> certain fashion, and his belief that modern compiler developers are
>> maliciously unhelpful regarding undefined behaviour.
>
> There's a difference between obtuseness and malice.
>
> I do not doubt that the authors of gcc honestly think that given something
> like [assume 32-bit "int"]:
And, presumably, 16-bit short?
> unsigned mul(unsigned short x, unsigned short y) { return x*y; }
Why would you write a signed multiply where you seem to be doing
unsigned arithmetic? It looks like you intended to write
unsigned mul(unsigned short x, unsigned short y) { return (unsigned)x*y; }
> unsigned mul65535(unsigned short x) { return mul(x, 65535); }
>
> a good compiler should ignores any code that would only be relevant if
> mul65535() were passed a value greater than 32768, and such behavior should
> be considered superior to simply having mul() yield the arithmetically-
> correct value in all cases. I would regard such a belief as downright
> obtuse, but that does not mean that I doubt the sincerity thereof.
Maybe the compiler developers wanted to optimise code based on undefined
signed arithmetic whilst providing a way for programmers to write
unsigned arithmetic if there is what they want. That seems reasonable
to me.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web