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 1 of 10 [1] 2 3 … 10 Next page →
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-27 22:36 +0200 |
| Subject | IEEE: C is the first programming language |
| Message-ID | <nnb615$1h2k$1@gioia.aioe.org> |
Richard Heathfield said: There are at least two (and quite possibly more than two) people in this group for whom C is their development language of choice: you, and me. Any more? Yes Richard, C has a LARGE mass of followers and is now the first. I quote from the IEEE Spectrum paper: http://spectrum.ieee.org/computing/software/the-2016-top-programming-languages <quote> After two years in second place, C has finally edged out Java for the top spot. Staying in the top five, Python has swapped places with C++ to take the No. 3 position, and C# has fallen out of the top five to be replaced with R <end quote> Good news!
[toc] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 16:42 -0700 |
| Message-ID | <373211b1-a3c7-4b42-85d7-0862cc962b08@googlegroups.com> |
| In reply to | #91178 |
On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: > After two years in second place, C has finally edged out Java for the > top spot. Staying in the top five, Python has swapped places with C++ to > take the No. 3 position, and C# has fallen out of the top five to be > replaced with R I wonder how that breaks down into the dialect favored by gcc, clang, et al. versus dialects that support pointer-based type punning, constrained overflow semantics, etc.?
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-28 01:47 +0200 |
| Message-ID | <nnbh76$kc$1@gioia.aioe.org> |
| In reply to | #91182 |
Le 28/07/2016 à 01:42, supercat@casperkitty.com a écrit : > On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: >> After two years in second place, C has finally edged out Java for the >> top spot. Staying in the top five, Python has swapped places with C++ to >> take the No. 3 position, and C# has fallen out of the top five to be >> replaced with R > > I wonder how that breaks down into the dialect favored by gcc, clang, et al. > versus dialects that support pointer-based type punning, ??? What's that??? "pointer-based type punning (prunning maybe) ???? constrained overflow > semantics, etc.? > ??? how can be an overflow "constrained" ??? Maybe "reported" i.e. compilers giving access to the overflow flag? Otherwise I do not know what you are saying here.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 17:20 -0700 |
| Message-ID | <20006afa-360c-4642-90d1-82f54ab020c2@googlegroups.com> |
| In reply to | #91183 |
On Wednesday, July 27, 2016 at 6:48:00 PM UTC-5, jacob navia wrote:
> Le 28/07/2016 à 01:42, supercat écrit :
> > On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote:
> >> After two years in second place, C has finally edged out Java for the
> >> top spot. Staying in the top five, Python has swapped places with C++ to
> >> take the No. 3 position, and C# has fallen out of the top five to be
> >> replaced with R
> >
> > I wonder how that breaks down into the dialect favored by gcc, clang, et al.
> > versus dialects that support pointer-based type punning,
>
> ??? What's that???
>
> "pointer-based type punning (prunning maybe) ????
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, even in cases where aliasing
is obvious. The authors of the C89 Standard may not have thought it
necessary to write rules for situations like:
void flip_aligned_pair_of_uint16(uint16_t *p)
{
*(uint32_t*)p ^= 0xFFFFFFFFU;
}
where a compiler that isn't deliberately obtuse would recognize that the
code is likely to modify things of type `uint16_t`, because they thought
compiler writers would have the common sense to recognize aliasing in such
common cases, and thus focused only on cases where it wouldn't be obvious
that compilers should recognize aliasing (e.g. if an lvalue is sometimes
accessed as signed and sometimes as unsigned).
> constrained overflow
> > semantics, etc.?
> >
>
> ??? how can be an overflow "constrained" ???
> Maybe "reported" i.e. compilers giving access to the overflow flag?
>
> Otherwise I do not know what you are saying here.
Constrained overflow behavior would imply that an expression like (x+1)>y
might arbitrarily yield 0 or 1 when x equals INT_MAX, but would not negate
the laws of time and causality. Many compilers historically treated
integer overflow using consistent two's-complement silent-wraparound
semantics, but many others would historically perform optimizations that
could cause overflowed values to behave like numbers outside the range of
"int" but whose lower bits were correct (so something like:
unsigned int mul(unsigned short x, unsigned short y) { return x*y; }
would yield arithmetically-correct results for all values of x and y whose
product would fit in unsigned int). Certainly the authors of the C Standard
would not have objected to implementations on hardware which behaved oddly
in case of overflow, behaving oddly in case of overflow. I don't think they
would have regarded as implementations which negate the laws of time and
causality in case of overflow even when using hardware whose overflow effects
are sane and predictable.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-27 18:03 -0700 |
| Message-ID | <d1efdc92-0b98-4e49-baaa-821d1cf81815@googlegroups.com> |
| In reply to | #91185 |
On Wednesday, July 27, 2016 at 8:20:42 PM UTC-4, supe...@casperkitty.com wrote: > On Wednesday, July 27, 2016 at 6:48:00 PM UTC-5, jacob navia wrote: > > Le 28/07/2016 à 01:42, supercat écrit : > > > On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: > > >> After two years in second place, C has finally edged out Java for the > > >> top spot. Staying in the top five, Python has swapped places with C++ to > > >> take the No. 3 position, and C# has fallen out of the top five to be > > >> replaced with R > > > > > > I wonder how that breaks down into the dialect favored by gcc, clang, et al. > > > versus dialects that support pointer-based type punning, > > > > ??? What's that??? > > > > "pointer-based type punning (prunning maybe) ???? > > 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? And, even if the target address is not 32-bit aligned, you can still access the data in 32-bit or 64-bit chunks (incurring the extra read and write penalties associated if they are unaligned). Algorithms like memcpy() and memmove() use a solution which moves the lead- in portion, the body, and the lead-out portion separately, so as to deal with fully aligned data for the bulk of the copy/move, and unaligned data movements only on the head and tail portions, and only if it's already not aligned. Any algorithm written in C can exploit this ... so I must not be understanding your point above. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 00:43 -0700 |
| Message-ID | <d6c7b2b0-bb10-4f7f-a270-1ec54e15ca32@googlegroups.com> |
| In reply to | #91186 |
On Thursday, July 28, 2016 at 2:03:50 AM UTC+1, Rick C. Hodgin wrote: > > Algorithms like memcpy() and memmove() use a solution which moves > the lead- in portion, the body, and the lead-out portion separately, > so as to deal with fully aligned data for the bulk of the copy/move, > and unaligned data movements only on the head and tail portions, and > only if it's already not aligned. > > Any algorithm written in C can exploit this ... so I must not be > understanding your point above. > So how would you write generic array operations? /* easy as a byte copying loop */ void swap(void *a, void *b, size_t size) /* reverse an array. easy on top of swap() */ void reverse(void *array, int N, size_t elsize) /* Move an element at old index so it is now at new index. this is harder one. We can use a buffer, and call memmove. but we've got a potential memory fail as we allocate the buffer. Or we could pass the buffer in, complicating the interface. or we could bubble the element to the desired position by repeated calls to swap, but that causes unneeded copying. */ void reorder(void *array, int N, size_t elsize, int oldindex, int newindex)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 05:12 -0700 |
| Message-ID | <67abd39b-8728-4a1e-a4cc-113d6304001f@googlegroups.com> |
| In reply to | #91213 |
On Thursday, July 28, 2016 at 3:43:46 AM UTC-4, Malcolm McLean wrote: > On Thursday, July 28, 2016 at 2:03:50 AM UTC+1, Rick C. Hodgin wrote: > > > > Algorithms like memcpy() and memmove() use a solution which moves > > the lead- in portion, the body, and the lead-out portion separately, > > so as to deal with fully aligned data for the bulk of the copy/move, > > and unaligned data movements only on the head and tail portions, and > > only if it's already not aligned. > > > > Any algorithm written in C can exploit this ... so I must not be > > understanding your point above. > > > So how would you write generic array operations? > > /* easy as a byte copying loop */ > void swap(void *a, void *b, size_t size) > > /* reverse an array. easy on top of swap() */ > void reverse(void *array, int N, size_t elsize) > > /* > Move an element at old index so it is now at new index. > this is harder one. We can use a buffer, and call memmove. > but we've got a potential memory fail as we allocate the buffer. > Or we could pass the buffer in, complicating the interface. > or we could bubble the element to the desired position > by repeated calls to swap, but that causes unneeded copying. > */ > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex) Arrays are merely size-replicated quantities within a larger quantity, potentially within a larger quantity, and so on. They resolve to blocks of fundamental data (bytes on a CPU bus). When you look at data from that point of view, it doesn't matter what the underlying thing is, you're dealing with fundamental ops at the lowest levels, and the only requirement is to do the math right to get the lengths and pointers setup for the operation. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 05:41 -0700 |
| Message-ID | <e6250857-10bd-4cb9-80d4-645bfa7693a0@googlegroups.com> |
| In reply to | #91222 |
On Thursday, July 28, 2016 at 1:12:24 PM UTC+1, Rick C. Hodgin wrote: > > > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex) > > Arrays are merely size-replicated quantities within a larger quantity, > potentially within a larger quantity, and so on. They resolve to blocks > of fundamental data (bytes on a CPU bus). > > When you look at data from that point of view, it doesn't matter what the > underlying thing is, you're dealing with fundamental ops at the lowest > levels, and the only requirement is to do the math right to get the lengths > and pointers setup for the operation. > Ok, so write reorder() as you would write it. We've got an array, and we want item at index oldindex to be moved so that its index becomes newindex, the indices of items in between will also be affected.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 06:02 -0700 |
| Message-ID | <a2986e78-7dcc-45a6-915a-594fd4b779b5@googlegroups.com> |
| In reply to | #91225 |
On Thursday, July 28, 2016 at 8:41:47 AM UTC-4, Malcolm McLean wrote: > On Thursday, July 28, 2016 at 1:12:24 PM UTC+1, Rick C. Hodgin wrote: > > > > > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex) > > > > Arrays are merely size-replicated quantities within a larger quantity, > > potentially within a larger quantity, and so on. They resolve to blocks > > of fundamental data (bytes on a CPU bus). > > > > When you look at data from that point of view, it doesn't matter what the > > underlying thing is, you're dealing with fundamental ops at the lowest > > levels, and the only requirement is to do the math right to get the lengths > > and pointers setup for the operation. > > > Ok, so write reorder() as you would write it. > We've got an array, and we want item at index oldindex to be moved so > that its index becomes newindex, the indices of items in between will also > be affected. Can I add a level of indirection so I'm not moving massive amounts of data, but only their pointers? :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 06:26 -0700 |
| Message-ID | <ec059764-fb97-428a-95c6-7871c1289b46@googlegroups.com> |
| In reply to | #91226 |
On Thursday, July 28, 2016 at 2:02:53 PM UTC+1, Rick C. Hodgin wrote: > On Thursday, July 28, 2016 at 8:41:47 AM UTC-4, Malcolm McLean wrote: > > On Thursday, July 28, 2016 at 1:12:24 PM UTC+1, Rick C. Hodgin wrote: > > > > > > > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex) > > > > > > Arrays are merely size-replicated quantities within a larger quantity, > > > potentially within a larger quantity, and so on. They resolve to blocks > > > of fundamental data (bytes on a CPU bus). > > > > > > When you look at data from that point of view, it doesn't matter what the > > > underlying thing is, you're dealing with fundamental ops at the lowest > > > levels, and the only requirement is to do the math right to get the lengths > > > and pointers setup for the operation. > > > > > Ok, so write reorder() as you would write it. > > We've got an array, and we want item at index oldindex to be moved so > > that its index becomes newindex, the indices of items in between will also > > be affected. > > Can I add a level of indirection so I'm not moving massive amounts of > data, but only their pointers? :-) > Not really. If user wants that, he can set up a parallel array of pointers to the first and do rearrangements on that. (You can of course devise sophisticated structures that will allow low big O operations on flat arrays, but that's not what I'm after). OTOH if the array holds only pointers, that makes some things easier. swap no longer needs to be generic.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 06:45 -0700 |
| Message-ID | <08c7a60a-f248-4219-a18c-c3a10e5fa485@googlegroups.com> |
| In reply to | #91228 |
On Thursday, July 28, 2016 at 9:26:46 AM UTC-4, Malcolm McLean wrote:
> On Thursday, July 28, 2016 at 2:02:53 PM UTC+1, Rick C. Hodgin wrote:
> > On Thursday, July 28, 2016 at 8:41:47 AM UTC-4, Malcolm McLean wrote:
> > > On Thursday, July 28, 2016 at 1:12:24 PM UTC+1, Rick C. Hodgin wrote:
> > > >
> > > > > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex)
> > > >
> > > > Arrays are merely size-replicated quantities within a larger quantity,
> > > > potentially within a larger quantity, and so on. They resolve to blocks
> > > > of fundamental data (bytes on a CPU bus).
> > > >
> > > > When you look at data from that point of view, it doesn't matter what the
> > > > underlying thing is, you're dealing with fundamental ops at the lowest
> > > > levels, and the only requirement is to do the math right to get the lengths
> > > > and pointers setup for the operation.
> > > >
> > > Ok, so write reorder() as you would write it.
> > > We've got an array, and we want item at index oldindex to be moved so
> > > that its index becomes newindex, the indices of items in between will also
> > > be affected.
> >
> > Can I add a level of indirection so I'm not moving massive amounts of
> > data, but only their pointers? :-)
> >
> Not really.
> If user wants that, he can set up a parallel array of pointers to the first and
> do rearrangements on that.
> (You can of course devise sophisticated structures that will allow low big O
> operations on flat arrays, but that's not what I'm after).
> OTOH if the array holds only pointers, that makes some things easier. swap
> no longer needs to be generic.
Alrighty. No indirection. I'll go through the rigamarole of this exercise
for ... (wait for it) ... $50.
You can find my PayPal "Donate" button:
http://www.visual-freepro.org/vjr/indexmain.html
:-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 09:11 -0700 |
| Message-ID | <6d6c2937-1fac-47da-b52b-8b7d12c1dd6c@googlegroups.com> |
| In reply to | #91229 |
On Thursday, July 28, 2016 at 2:47:00 PM UTC+1, Rick C. Hodgin wrote:
> On Thursday, July 28, 2016 at 9:26:46 AM UTC-4, Malcolm McLean wrote:
> > On Thursday, July 28, 2016 at 2:02:53 PM UTC+1, Rick C. Hodgin wrote:
> > > On Thursday, July 28, 2016 at 8:41:47 AM UTC-4, Malcolm McLean wrote:
> > > > On Thursday, July 28, 2016 at 1:12:24 PM UTC+1, Rick C. Hodgin wrote:
> > > > >
> > > > > > void reorder(void *array, int N, size_t elsize, int oldindex, int newindex)
> > > > >
> > > > > Arrays are merely size-replicated quantities within a larger quantity,
> > > > > potentially within a larger quantity, and so on. They resolve to blocks
> > > > > of fundamental data (bytes on a CPU bus).
> > > > >
> > > > > When you look at data from that point of view, it doesn't matter what the
> > > > > underlying thing is, you're dealing with fundamental ops at the lowest
> > > > > levels, and the only requirement is to do the math right to get the lengths
> > > > > and pointers setup for the operation.
> > > > >
> > > > Ok, so write reorder() as you would write it.
> > > > We've got an array, and we want item at index oldindex to be moved so
> > > > that its index becomes newindex, the indices of items in between will also
> > > > be affected.
> > >
> > > Can I add a level of indirection so I'm not moving massive amounts of
> > > data, but only their pointers? :-)
> > >
> > Not really.
> > If user wants that, he can set up a parallel array of pointers to the first and
> > do rearrangements on that.
> > (You can of course devise sophisticated structures that will allow low big O
> > operations on flat arrays, but that's not what I'm after).
> > OTOH if the array holds only pointers, that makes some things easier. swap
> > no longer needs to be generic.
>
> Alrighty. No indirection. I'll go through the rigamarole of this exercise
> for ... (wait for it) ... $50.
>
> You can find my PayPal "Donate" button:
>
> http://www.visual-freepro.org/vjr/indexmain.html
>
> :-)
>
I'd expect any reg here to be able to just do it.
(untested but should be OK)
void reorder(void array, int N, size_t elsize, int oldindex, int newindex)
{
int i;
unsigned char *ptr = array;
if(oldindex < newindex)
{
for(i=oldindex; i<newindex;i++)
swap( ptr + i * elsize, ptr + (i+1) * elsize, elsize);
}
else if(oldindex > newindex)
{
for(i=oldindex; i>newindex;i--)
swap( ptr + i * elsize, ptr + (i-1) * elsize, elsize);
}
}
The question is how to squeeze out a bit more efficiency.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 09:30 -0700 |
| Message-ID | <ac8bbc7e-2757-4e60-948e-54ea81c60f29@googlegroups.com> |
| In reply to | #91245 |
On Thursday, July 28, 2016 at 12:11:13 PM UTC-4, Malcolm McLean wrote: > On Thursday, July 28, 2016 at 2:47:00 PM UTC+1, Rick C. Hodgin wrote: > > Alrighty. No indirection. I'll go through the rigamarole of this exercise > > for ... (wait for it) ... $50. > > > > You can find my PayPal "Donate" button: > > > > http://www.visual-freepro.org/vjr/indexmain.html > > > > :-) > > The question is how to squeeze out a bit more efficiency. Exactly. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-28 14:03 +0200 |
| Message-ID | <nncsau$bbp$1@dont-email.me> |
| In reply to | #91186 |
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 Wednesday, July 27, 2016 at 6:48:00 PM UTC-5, jacob navia wrote: >>> Le 28/07/2016 à 01:42, supercat écrit : >>>> On Wednesday, July 27, 2016 at 3:37:07 PM UTC-5, jacob navia wrote: >>>>> After two years in second place, C has finally edged out Java for the >>>>> top spot. Staying in the top five, Python has swapped places with C++ to >>>>> take the No. 3 position, and C# has fallen out of the top five to be >>>>> replaced with R >>>> >>>> I wonder how that breaks down into the dialect favored by gcc, clang, et al. >>>> versus dialects that support pointer-based type punning, >>> >>> ??? What's that??? >>> >>> "pointer-based type punning (prunning maybe) ???? >> >> 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. As has been pointed out to him endless times, C has never defined this behaviour. Later C standards have clarified the situation a little, but not changed it. And while it is certainly true that many compilers will implement such casts and accesses in the way that seems obvious, I don't know of any that guarantee such behaviour. Since it is something outside the C standards, it would need a written note in the compiler's documentation before you could be sure that it work. I have read many compiler reference manuals through the years, but don't remember ever having seen such a statement. Of course, a compiler can happily generate "obvious" code for such casts without documenting it - but you should not rely on that. C provides methods for safely converting between pointer types, or accessing data in different ways and of different sizes. You can use unions, memcpy, access through char pointers, volatile pointers, etc. You can also simply the data in the original (known safe) size and hope the compiler will optimise the code well enough (it is more important that the code is correct than efficient). And compilers may have extensions that will help. Unfortunately, there is no simple method that will generate the desired effect and efficient code on a wide variety of compilers, targets, and compiler options. It would be nice if the standards provided a solution here (such as a type qualifier "may_alias" allowing the creation of special uint16_t or uint32_t pointers that can alias data of any type). But the standards don't have a solution here, and they never have had. > And, even if the target address isnot 32-bit aligned, you can still > access the data in 32-bit or 64-bit chunks (incurring the extra read > and write penalties associated if they are unaligned). That /may/ be the case - but it may not be. On many processors, misaligned accesses cause hardware fault traps - they are simply not supported. On some, such as the x86, they are allowed for some instructions but not others (in particular, some SIMD instructions require aligned accesses). And on many, the misaligned accesses can be significantly slower than multiple explicit smaller accesses. > > Algorithms like memcpy() and memmove() use a solution which moves the lead- > in portion, the body, and the lead-out portion separately, so as to deal > with fully aligned data for the bulk of the copy/move, and unaligned data > movements only on the head and tail portions, and only if it's already not > aligned. That is often the case - but it depends on the implementation of these functions. These features make the functions faster for large copies, but slower for small copies. And compilers will sometimes inline a locally generated version, especially if it knows the alignment and the size of the copy. > > Any algorithm written in C can exploit this ... so I must not be understanding > your point above. > Don't worry - you are not the only one who has trouble understanding some of Supercat's points (or why he feels they need to be brought up in every single thread).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 05:24 -0700 |
| Message-ID | <4b5deb70-4e84-405b-b23b-97f7d8950975@googlegroups.com> |
| In reply to | #91221 |
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.
> As has been pointed out to him endless times, C has never defined this
> behaviour. Later C standards have clarified the situation a little, but
> not changed it.
>
> And while it is certainly true that many compilers will implement such
> casts and accesses in the way that seems obvious, I don't know of any
> that guarantee such behaviour.
I agree. But, I think for a particular compiler, or genre of compilers
(such as x86 on standard OSes), it is reasonable to rely on the specific
implementation-allowed behavior in such cases, knowing that it could
then theoretically break at any point. And if you are doing such things,
it would be worth incorporating unit tests into your compiled project to
validate that it is continually working as expected.
> Since it is something outside the C
> standards, it would need a written note in the compiler's documentation
> before you could be sure that it work. I have read many compiler
> reference manuals through the years, but don't remember ever having seen
> such a statement. Of course, a compiler can happily generate "obvious"
> code for such casts without documenting it - but you should not rely on
> that.
Agreed completely.
> C provides methods for safely converting between pointer types, or
> accessing data in different ways and of different sizes. You can use
> unions, memcpy, access through char pointers, volatile pointers, etc.
> You can also simply the data in the original (known safe) size and hope
> the compiler will optimise the code well enough (it is more important
> that the code is correct than efficient). And compilers may have
> extensions that will help.
>
> Unfortunately, there is no simple method that will generate the desired
> effect and efficient code on a wide variety of compilers, targets, and
> compiler options. It would be nice if the standards provided a solution
> here (such as a type qualifier "may_alias" allowing the creation of
> special uint16_t or uint32_t pointers that can alias data of any type).
> But the standards don't have a solution here, and they never have had.
This is one of the reasons I remove many C standard features from CAlive's
philosophy. I look at things from the data processing point of view, and
not from a language-impingement point of view.
Hardware is capable of doing certain things, so I expose those features.
In addition, human beings expect certain things from calculations, so I
look at things from that expectation point of view, even if it's a small
sacrifice in performance to get there (such as upsizing a lesser signed
or unsigned type to perform a computation which could otherwise overflow/
underflow).
> > And, even if the target address isnot 32-bit aligned, you can still
> > access the data in 32-bit or 64-bit chunks (incurring the extra read
> > and write penalties associated if they are unaligned).
>
> That /may/ be the case - but it may not be. On many processors,
> misaligned accesses cause hardware fault traps - they are simply not
> supported. On some, such as the x86, they are allowed for some
> instructions but not others (in particular, some SIMD instructions
> require aligned accesses). And on many, the misaligned accesses can be
> significantly slower than multiple explicit smaller accesses.
True. If you're going across multiple platforms, you'll have a naturally
purposed and reasoned approach to very conservative data processing,
though possibly with some specialized target-specific optimizations so as
to not be bogged too far down by the needs of "data conservancy." :-)
> > Algorithms like memcpy() and memmove() use a solution which moves the lead-
> > in portion, the body, and the lead-out portion separately, so as to deal
> > with fully aligned data for the bulk of the copy/move, and unaligned data
> > movements only on the head and tail portions, and only if it's already not
> > aligned.
>
> That is often the case - but it depends on the implementation of these
> functions. These features make the functions faster for large copies,
> but slower for small copies. And compilers will sometimes inline a
> locally generated version, especially if it knows the alignment and the
> size of the copy.
Yep.
> > Any algorithm written in C can exploit this ... so I must not be understanding
> > your point above.
>
> Don't worry - you are not the only one who has trouble understanding
> some of Supercat's points (or why he feels they need to be brought up in
> every single thread).
I think Supercat has demonstrated a comprehensive knowledge and insight
into compiler architecture ... and from the position of understanding the
philosophy of compiler architectures. He, like any of us, may have some
of the details relating to real-world things incorrect in his thinking,
but that's just a matter of being corrected, and not a fundamental flaw
in the person, or in the approach.
I admire Supercat in his posts. And I have learned a lot from the many
discussions they've spawned.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-29 01:14 +0200 |
| Message-ID | <nne3kh$rl3$1@dont-email.me> |
| In reply to | #91224 |
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. Certainly it is unlikely that the compiler will see a benefit in doing something unexpected with code that uses such pointer casting to access arrays of data. But there are no guarantees. The compiler /could/ note that what you are doing has no defined effect in C, and therefore it is safe (and very efficient) to simply omit that piece of code. Note that I don't really agree on the aliasing rules here - I think it would be better if C had defined accesses through pointer casts in the "obvious" way. But C is what it is - you either live with it, use a different language (even if you have to write it yourself!), or use compilers or flags that give you what you want. (For gcc, the "-fno-strict-alias" flag will do this - as will the "may_alias" attribute on the pointer types.) > 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. > >> As has been pointed out to him endless times, C has never defined this >> behaviour. Later C standards have clarified the situation a little, but >> not changed it. >> >> And while it is certainly true that many compilers will implement such >> casts and accesses in the way that seems obvious, I don't know of any >> that guarantee such behaviour. > > I agree. But, I think for a particular compiler, or genre of compilers > (such as x86 on standard OSes), it is reasonable to rely on the specific > implementation-allowed behavior in such cases, knowing that it could > then theoretically break at any point. And if you are doing such things, > it would be worth incorporating unit tests into your compiled project to > validate that it is continually working as expected. That's fine. Portability is sometimes an issue, sometimes not. If you know your compiler behaves in a particular manner, then I think it is fair enough to rely on that. Whether you get that knowledge through testing, documentation, talking to the developers, etc., is up to you and the needs of the project. > >>> Any algorithm written in C can exploit this ... so I must not be understanding >>> your point above. >> >> Don't worry - you are not the only one who has trouble understanding >> some of Supercat's points (or why he feels they need to be brought up in >> every single thread). > > I think Supercat has demonstrated a comprehensive knowledge and insight > into compiler architecture ... and from the position of understanding the > philosophy of compiler architectures. He, like any of us, may have some > of the details relating to real-world things incorrect in his thinking, > but that's just a matter of being corrected, and not a fundamental flaw > in the person, or in the approach. > > I admire Supercat in his posts. And I have learned a lot from the many > discussions they've spawned. > 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. But if we all agreed, what point would there be in a discussion group? :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-07-28 18:27 -0700 |
| Message-ID | <da0382e0-bb64-4e97-b148-ea5c33395916@googlegroups.com> |
| In reply to | #91289 |
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.
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. :-)
> >> As has been pointed out to him endless times, C has never defined this
> >> behaviour. Later C standards have clarified the situation a little, but
> >> not changed it.
> >>
> >> And while it is certainly true that many compilers will implement such
> >> casts and accesses in the way that seems obvious, I don't know of any
> >> that guarantee such behaviour.
> >
> > I agree. But, I think for a particular compiler, or genre of compilers
> > (such as x86 on standard OSes), it is reasonable to rely on the specific
> > implementation-allowed behavior in such cases, knowing that it could
> > then theoretically break at any point. And if you are doing such things,
> > it would be worth incorporating unit tests into your compiled project to
> > validate that it is continually working as expected.
>
> That's fine. Portability is sometimes an issue, sometimes not. If you
> know your compiler behaves in a particular manner, then I think it is
> fair enough to rely on that. Whether you get that knowledge through
> testing, documentation, talking to the developers, etc., is up to you
> and the needs of the project.
>
> >
> >>> Any algorithm written in C can exploit this ... so I must not be understanding
> >>> your point above.
> >>
> >> Don't worry - you are not the only one who has trouble understanding
> >> some of Supercat's points (or why he feels they need to be brought up in
> >> every single thread).
> >
> > I think Supercat has demonstrated a comprehensive knowledge and insight
> > into compiler architecture ... and from the position of understanding the
> > philosophy of compiler architectures. He, like any of us, may have some
> > of the details relating to real-world things incorrect in his thinking,
> > but that's just a matter of being corrected, and not a fundamental flaw
> > in the person, or in the approach.
> >
> > I admire Supercat in his posts. And I have learned a lot from the many
> > discussions they've spawned.
> >
>
> 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.
> 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-29 12:08 +0200 |
| Message-ID | <nnf9v7$u4u$1@dont-email.me> |
| In reply to | #91296 |
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.
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
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.
> 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");".
>
>>
>> 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.
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...".
>
>> 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-29 11:37 +0100 |
| Message-ID | <87twf8ybld.fsf@bsb.me.uk> |
| In reply to | #91306 |
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>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-29 12:51 +0200 |
| Message-ID | <nnfcge$6d6$1@dont-email.me> |
| In reply to | #91308 |
On 29/07/16 12:37, Ben Bacarisse wrote:
> 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).
>
Of course. A /really/ clever compiler gets its optimisations right!
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web