Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100060 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2016-12-22 22:47 -0500 |
| Last post | 2017-01-07 18:51 -0500 |
| Articles | 20 on this page of 161 — 27 participants |
Back to article view | Back to comp.lang.c
How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2016-12-22 22:47 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ike Naar <ike@iceland.freeshell.org> - 2016-12-23 06:56 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 11:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 11:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 12:09 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 12:34 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 12:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 20:58 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 21:09 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-23 13:36 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 12:39 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-24 16:46 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 13:04 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-25 09:43 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 22:01 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-24 15:21 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? luser droog <luser.droog@gmail.com> - 2016-12-24 15:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-25 16:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-25 13:13 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 09:42 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Manfred <noname@invalid.add> - 2017-02-03 20:40 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:47 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-29 14:33 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:04 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-01 11:38 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 13:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:17 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-03 13:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 17:29 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 10:10 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 08:33 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2016-12-27 20:22 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 10:18 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-27 13:28 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 15:55 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:01 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 16:40 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-29 06:27 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:47 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:45 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:26 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? asetofsymbols@gmail.com - 2017-01-01 13:03 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:04 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 08:27 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-02 12:37 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 10:42 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 21:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-14 11:15 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-16 00:31 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-18 21:45 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 18:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:49 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-10 01:57 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-10 10:32 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 08:44 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-02 10:42 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-02 13:06 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-03 10:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 07:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 09:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 12:36 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:51 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 13:08 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 14:07 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 11:28 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-03 22:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 11:53 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-03 18:39 -0600
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 00:47 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:49 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:45 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? David Brown <david.brown@hesbynett.no> - 2017-01-04 20:05 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 15:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-04 13:09 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 00:12 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:50 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-04 07:25 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-01-04 15:29 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-04 10:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-03 16:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-07 18:59 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-07 15:59 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-08 03:27 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-07 21:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-03 16:22 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 07:05 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:09 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-13 15:40 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-13 15:56 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 15:58 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-14 09:29 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:14 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-31 10:57 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 08:07 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-02-03 08:43 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:43 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-18 21:46 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-18 09:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2016-12-27 14:37 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 12:33 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 17:21 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 13:08 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 22:33 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-23 14:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 15:12 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 01:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-24 04:12 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-24 15:12 +0000
Re: Inadvertent trolls Noob <root@127.0.0.1> - 2016-12-24 11:34 +0100
Re: Inadvertent trolls BartC <bc@freeuk.com> - 2016-12-24 12:47 +0000
Typo or freudian slip? (Was: Inadvertent trolls) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-24 13:13 +0000
Re: Typo or freudian slip? (Was: Inadvertent trolls) BartC <bc@freeuk.com> - 2016-12-24 14:02 +0000
Re: Inadvertent trolls Keith Thompson <kst-u@mib.org> - 2016-12-24 12:36 -0800
Re: Inadvertent trolls Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-24 13:59 -0800
Re: Inadvertent trolls Gareth Owen <gwowen@gmail.com> - 2016-12-26 18:38 +0000
Re: C interpreter Noob <root@127.0.0.1> - 2016-12-24 23:39 +0100
Re: C interpreter BartC <bc@freeuk.com> - 2016-12-25 00:32 +0000
Re: Inadvertent trolls jacobnavia <jacob@jacob.remcomp.fr> - 2017-01-01 11:10 +0100
Re: Inadvertent trolls BartC <bc@freeuk.com> - 2017-01-01 11:54 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-23 09:52 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-04 23:38 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ian Collins <ian-news@hotmail.com> - 2017-01-05 17:49 +1300
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? David Brown <david.brown@hesbynett.no> - 2017-01-05 09:57 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Noob <root@127.0.0.1> - 2017-01-05 09:50 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-23 11:16 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-23 04:36 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-23 13:24 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 01:35 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:06 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-28 18:33 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:13 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-02 02:53 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:09 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-13 08:51 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-13 10:28 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-13 10:00 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? supercat@casperkitty.com - 2017-01-13 10:34 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:00 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:17 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2017-01-14 13:52 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-16 00:18 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Keith Thompson <kst-u@mib.org> - 2016-12-28 18:40 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:48 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 17:01 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2016-12-29 01:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 01:27 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 01:59 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-23 13:01 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 14:08 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-05 00:05 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2017-01-05 12:08 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-05 10:41 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2017-01-05 18:08 +0100
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-05 17:08 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? BartC <bc@freeuk.com> - 2017-01-05 12:02 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? James Kuyper <jameskuyper@verizon.net> - 2017-01-05 14:36 -0500
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? antispam@math.uni.wroc.pl - 2017-01-07 20:20 +0000
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-07 12:55 -0800
Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? DFS <nospam@dfs.com> - 2017-01-07 18:51 -0500
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:47 -0800 |
| Message-ID | <kfninpxspqh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100591 |
supercat@casperkitty.com writes: > On Thursday, December 29, 2016 at 3:34:57 AM UTC-6, Tim Rentsch wrote: >> Being a very experienced C programmer is not the same as having >> an in-depth familiarity with the ISO C standard. Maybe they >> should be, but they aren't. Consider the reaction of the Linux >> development community to the so-called "strict aliasing" rules. > > What annoys Linux programmers is [...] My comment was only about their initial surprise, nothing more.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-30 08:45 +1300 |
| Message-ID | <ecl7f5Fpuo9U1@mid.individual.net> |
| In reply to | #100562 |
On 12/29/16 10:34 PM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 12/28/16 10:55 AM, Robert Wessel wrote: >>> [...] >>> My point is that the OS writers will probably be better at >>> implementing a given function to use the OS well, but are rather >>> more likely to miss required subtleties of the C library as seen >>> by the C programmer. >> >> Maybe, but what are the OS writers if not (very experienced) C >> programmers? > > Being a very experienced C programmer is not the same as having > an in-depth familiarity with the ISO C standard. Maybe they > should be, but they aren't. Consider the reaction of the Linux > development community to the so-called "strict aliasing" rules. > > For that matter, presumably you count yourself as an experienced > C++ developer. Would you also say that you are thoroughly > familiar with the ISO C++ standard? No I wouldn't say that I am thoroughly familiar with it. But a standard is just another requirements document, so if I (or any other experienced programmer) were tasked with implementing a part of it, I very quickly would be. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 15:26 +0000 |
| Message-ID | <58691e79.5831812@news.xs4all.nl> |
| In reply to | #100599 |
Ian Collins <ian-news@hotmail.com> wrote: > On 12/29/16 10:34 PM, Tim Rentsch wrote: > > Ian Collins <ian-news@hotmail.com> writes: > > > >> Maybe, but what are the OS writers if not (very experienced) C > >> programmers? > > > > Being a very experienced C programmer is not the same as having > > an in-depth familiarity with the ISO C standard. Maybe they > > should be, but they aren't. Consider the reaction of the Linux > > development community to the so-called "strict aliasing" rules. > > > > For that matter, presumably you count yourself as an experienced > > C++ developer. Would you also say that you are thoroughly > > familiar with the ISO C++ standard? > > No I wouldn't say that I am thoroughly familiar with it. But a standard > is just another requirements document, so if I (or any other experienced > programmer) were tasked with implementing a part of it, I very quickly > would be. All of it? I've seen quite a few people claim that they were intimately familiar with _parts_ of the C++ Standard, and I believe them. I've seen people claim that they were deeply familiar with the C Standard, and I believe some, though not all, of them. (As for me, I'm only more-or-less familiar with it, which is still more than I can believe of some of the aforementioned.) I don't think I've ever seen anyone claim to be nearly as familiar with the _entire_ C++ Standard, and if I had, I'd have a hard time believing it. Nevertheless, I would think that those OS implementors tasked with writing the API _should_ be thoroughly familiar with the _entire_ Standard of whatever language they're targeting, and the implementors of a language implementation to be equally familiar with the API of the OS they're targeting. Richard
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2017-01-01 13:03 -0800 |
| Message-ID | <f388b202-1efa-4b7b-bcb9-5bd2826c1801@googlegroups.com> |
| In reply to | #100781 |
So for you should be not possible someone, know only 20% of standard and use only that, can write code good enough People like to add I like to cut
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 03:04 -0800 |
| Message-ID | <kfneg0lsoxb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100599 |
Ian Collins <ian-news@hotmail.com> writes: > On 12/29/16 10:34 PM, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 12/28/16 10:55 AM, Robert Wessel wrote: >>>> [...] >>>> My point is that the OS writers will probably be better at >>>> implementing a given function to use the OS well, but are rather >>>> more likely to miss required subtleties of the C library as seen >>>> by the C programmer. >>> >>> Maybe, but what are the OS writers if not (very experienced) C >>> programmers? >> >> Being a very experienced C programmer is not the same as having >> an in-depth familiarity with the ISO C standard. Maybe they >> should be, but they aren't. Consider the reaction of the Linux >> development community to the so-called "strict aliasing" rules. >> >> For that matter, presumably you count yourself as an experienced >> C++ developer. Would you also say that you are thoroughly >> familiar with the ISO C++ standard? > > No I wouldn't say that I am thoroughly familiar with it. But a > standard is just another requirements document, so if I (or any other > experienced programmer) were tasked with implementing a part of it, I > very quickly would be. I hope you won't be offended if I say this doesn't convince me. I have gone through this process for the ISO C standard, and it has been a long process. I also have gone through the exercise of reading an ISO C++ standard from cover to cover -- not absorbing everything, just reading it once through. Based on those experiences I believe the magnitude of the task is a bit larger than you seem to expect. I hasten to add this means no disrespect for your abilities, I believe it would be a daunting task for pretty much anyone.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 08:27 +1300 |
| Message-ID | <ecvnshFk6mqU1@mid.individual.net> |
| In reply to | #100864 |
On 01/ 3/17 12:04 AM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 12/29/16 10:34 PM, Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 12/28/16 10:55 AM, Robert Wessel wrote: >>>>> [...] >>>>> My point is that the OS writers will probably be better at >>>>> implementing a given function to use the OS well, but are rather >>>>> more likely to miss required subtleties of the C library as seen >>>>> by the C programmer. >>>> >>>> Maybe, but what are the OS writers if not (very experienced) C >>>> programmers? >>> >>> Being a very experienced C programmer is not the same as having >>> an in-depth familiarity with the ISO C standard. Maybe they >>> should be, but they aren't. Consider the reaction of the Linux >>> development community to the so-called "strict aliasing" rules. >>> >>> For that matter, presumably you count yourself as an experienced >>> C++ developer. Would you also say that you are thoroughly >>> familiar with the ISO C++ standard? >> >> No I wouldn't say that I am thoroughly familiar with it. But a >> standard is just another requirements document, so if I (or any other >> experienced programmer) were tasked with implementing a part of it, I >> very quickly would be. > > I hope you won't be offended if I say this doesn't convince > me. I have gone through this process for the ISO C standard, and > it has been a long process. A couple of points: I wasn't suggesting that one person would be implementing the entire (I did say "part of it") standard library, it would be a team effort. As a specification, the library section of the standard is well written. Quality wise, it is way ahead of many that I have had to work from. If you remember a while back we had a thread here covering the implementation of strtol() and friends which given the quality of the specification was a straightforward task. In the case of POSIX (as originally discussed), the test suite is already written. When compared to many project specifications, it is on the small side. The current project I am working on is in the order of 80 man years of work. The specifications are large and complex and no where near as detailed or stable as the standard library specification. > I also have gone through the > exercise of reading an ISO C++ standard from cover to cover -- > not absorbing everything, just reading it once through. Based on > those experiences I believe the magnitude of the task is a bit > larger than you seem to expect. I hasten to add this means no > disrespect for your abilities, I believe it would be a daunting > task for pretty much anyone. In its entirety for on person yes, for a team, no. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 12:37 -0800 |
| Message-ID | <8dd31574-256d-480b-a680-988a875760fc@googlegroups.com> |
| In reply to | #100893 |
On Monday, January 2, 2017 at 1:27:21 PM UTC-6, Ian Collins wrote: > As a specification, the library section of the standard is well written. Perhaps by the standards of the day it was reasonable, but many aspects of the Standard library are poorly designed (e.g. strncat is only useful in cases where code doesn't know the length of the string in the destination buffer but nonetheless knows that a specified amount of space will remain within it), and the text of the Standard is often lax in its specifications of corner-case details. If all or nearly all extant implementations will behave consistently in a particular corner case, and if many programmers expect such behavior, a quality standard must either mandate the behavior or expressly say that implementations may deviate from such behavior. If a standard fails to do either of those things, some programmers will expect implementations to behave in the commonplace fashion, while some compiler writers will believe that they are entitled to do otherwise. Since the purpose of the standard is to ensure that compiler behavior is consistent with programmer expectations, a standard which fails to achieve that should be considered defective.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 10:42 +1300 |
| Message-ID | <ecvvr3Flsf9U1@mid.individual.net> |
| In reply to | #100904 |
On 01/ 3/17 09:37 AM, supercat@casperkitty.com wrote: > On Monday, January 2, 2017 at 1:27:21 PM UTC-6, Ian Collins wrote: >> As a specification, the library section of the standard is well written. > > Perhaps by the standards of the day it was reasonable, but many aspects of > the Standard library are poorly designed (e.g. strncat is only useful in > cases where code doesn't know the length of the string in the destination > buffer but nonetheless knows that a specified amount of space will remain > within it), and the text of the Standard is often lax in its specifications > of corner-case details. The perfect specification does not exist. The library section of the standard is better than most. > If all or nearly all extant implementations will behave consistently in a > particular corner case, and if many programmers expect such behavior, a > quality standard must either mandate the behavior or expressly say that > implementations may deviate from such behavior. If a standard fails to > do either of those things, some programmers will expect implementations > to behave in the commonplace fashion, while some compiler writers will > believe that they are entitled to do otherwise. Since the purpose of the > standard is to ensure that compiler behavior is consistent with programmer > expectations, a standard which fails to achieve that should be considered > defective. So raise a defect report. How many have you submitted so far? With all of your whining, there must have be quite a few with your name attached. Maybe almost as many as BartC? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-12 21:24 -0800 |
| Message-ID | <kfnwpdzr0ps.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100893 |
Ian Collins <ian-news@hotmail.com> writes: > On 01/ 3/17 12:04 AM, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 12/29/16 10:34 PM, Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> On 12/28/16 10:55 AM, Robert Wessel wrote: >>>>>> [...] >>>>>> My point is that the OS writers will probably be better at >>>>>> implementing a given function to use the OS well, but are rather >>>>>> more likely to miss required subtleties of the C library as seen >>>>>> by the C programmer. >>>>> >>>>> Maybe, but what are the OS writers if not (very experienced) C >>>>> programmers? >>>> >>>> Being a very experienced C programmer is not the same as having >>>> an in-depth familiarity with the ISO C standard. Maybe they >>>> should be, but they aren't. Consider the reaction of the Linux >>>> development community to the so-called "strict aliasing" rules. >>>> >>>> For that matter, presumably you count yourself as an experienced >>>> C++ developer. Would you also say that you are thoroughly >>>> familiar with the ISO C++ standard? >>> >>> No I wouldn't say that I am thoroughly familiar with it. But a >>> standard is just another requirements document, so if I (or any other >>> experienced programmer) were tasked with implementing a part of it, I >>> very quickly would be. >> >> I hope you won't be offended if I say this doesn't convince >> me. I have gone through this process for the ISO C standard, and >> it has been a long process. > > A couple of points: > > I wasn't suggesting that one person would be implementing the entire > (I did say "part of it") standard library, it would be a team effort. > > As a specification, the library section of the standard is well > written. Quality wise, it is way ahead of many that I have had to work > from. If you remember a while back we had a thread here covering the > implementation of strtol() and friends which given the quality of the > specification was a straightforward task. > > In the case of POSIX (as originally discussed), the test suite is > already written. We have some topic skew here. My last comment was a response on a later topic, whereas your followup (mostly) presumes the context of an earlier topic. So even though your comments are relevant to some of the discussion up-thread, they don't really address the questions raised about your later comments. > When compared to many project specifications, it is on the small > side. The current project I am working on is in the order of 80 man > years of work. The specifications are large and complex and no where > near as detailed or stable as the standard library specification. I think you are saying one of two things here. Either: one, the large and complex specifications took a long time to master and understand; or two, the large and complex specifications were bigger and less well-written than the C++ standard, presumably also with just as much interdependency, yet they could be well understood fairly quickly (and so by implication the C++ standard could be understood at least that quickly). If what you're saying is the first thing, that seems consistent what what I said about the C++ standard. If what you're saying is the second thing, I don't see any reason to be less skeptical about that claim than about the earlier claim about the C++ standard. Is one of those two readings what you meant, or did were you trying to say something else that didn't occur to me? >> I also have gone through the >> exercise of reading an ISO C++ standard from cover to cover -- >> not absorbing everything, just reading it once through. Based on >> those experiences I believe the magnitude of the task is a bit >> larger than you seem to expect. I hasten to add this means no >> disrespect for your abilities, I believe it would be a daunting >> task for pretty much anyone. > > In its entirety for on person yes, for a team, no. I think you're implying that understanding the whole can proceed faster by breaking up the task into pieces and having different people work on different parts independently. First off this isn't what I was asking about (and I see now that I may have misunderstood that you were answering a question different than the one I asked), but even ignoring that, being able to go faster in parallel assumes there is comparatively little inter-dependence between different parts of the document. IME both the C standard and the C++ standard have a fair amount of inter-dependence, and different sections cannot be read effectively in isolation. So I doubt there would be much speedup. I agree that parts of C++ can be understood and implemented pretty much in isolation, eg, lots of the STL. On the other hand those parts tend to be those least likely in need of re-implementation, because they can be (almost completely) implemented in the core language, and so would be portable between different implementations. I understand that you are optimistic about your abilities (or those of your team) but I don't see any supporting reasoning to go with that - just your claim that it wouldn't be that hard. Do you have anything more to offer than just a claim about how easy or difficult it would be? (To be clear, the "it" here means becoming thoroughly familiar with the ISO C++ standard.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-14 11:15 +1300 |
| Message-ID | <edt1r8F4adeU3@mid.individual.net> |
| In reply to | #101579 |
On 01/13/17 06:24 PM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 01/ 3/17 12:04 AM, Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 12/29/16 10:34 PM, Tim Rentsch wrote: >>>>> Ian Collins <ian-news@hotmail.com> writes: >>>>> >>>>>> On 12/28/16 10:55 AM, Robert Wessel wrote: >>>>>>> [...] >>>>>>> My point is that the OS writers will probably be better at >>>>>>> implementing a given function to use the OS well, but are rather >>>>>>> more likely to miss required subtleties of the C library as seen >>>>>>> by the C programmer. >>>>>> >>>>>> Maybe, but what are the OS writers if not (very experienced) C >>>>>> programmers? >>>>> >>>>> Being a very experienced C programmer is not the same as having >>>>> an in-depth familiarity with the ISO C standard. Maybe they >>>>> should be, but they aren't. Consider the reaction of the Linux >>>>> development community to the so-called "strict aliasing" rules. >>>>> >>>>> For that matter, presumably you count yourself as an experienced >>>>> C++ developer. Would you also say that you are thoroughly >>>>> familiar with the ISO C++ standard? >>>> >>>> No I wouldn't say that I am thoroughly familiar with it. But a >>>> standard is just another requirements document, so if I (or any other >>>> experienced programmer) were tasked with implementing a part of it, I >>>> very quickly would be. >>> >>> I hope you won't be offended if I say this doesn't convince >>> me. I have gone through this process for the ISO C standard, and >>> it has been a long process. >> >> A couple of points: >> >> I wasn't suggesting that one person would be implementing the entire >> (I did say "part of it") standard library, it would be a team effort. >> >> As a specification, the library section of the standard is well >> written. Quality wise, it is way ahead of many that I have had to work >> from. If you remember a while back we had a thread here covering the >> implementation of strtol() and friends which given the quality of the >> specification was a straightforward task. >> >> In the case of POSIX (as originally discussed), the test suite is >> already written. > > We have some topic skew here. My last comment was a response > on a later topic, whereas your followup (mostly) presumes the > context of an earlier topic. So even though your comments > are relevant to some of the discussion up-thread, they don't > really address the questions raised about your later comments. I'm not sure which specific comments you were referring to, but when I say that a big part of every professional programmer's job is interpreting often very complex specifications I'm sure you won't disagree. I'm also pretty sure that you would agree with my statements that the quality of the C (and C++) standard's requirements for the library being better than most we have to deal with. So I don't see how you can claim that a programmer experienced in the language, but not currently intimately familiar with the standard would not be able to implement some (or all with sufficient time) of the standard library. I mention the implementation of strtol() as a concrete example which I believe strengthens my claim. >> When compared to many project specifications, it is on the small >> side. The current project I am working on is in the order of 80 man >> years of work. The specifications are large and complex and no where >> near as detailed or stable as the standard library specification. > > I think you are saying one of two things here. Either: one, the > large and complex specifications took a long time to master and > understand; or two, the large and complex specifications were > bigger and less well-written than the C++ standard, presumably > also with just as much interdependency, yet they could be well > understood fairly quickly (and so by implication the C++ standard > could be understood at least that quickly). If what you're > saying is the first thing, that seems consistent what what I said > about the C++ standard. If what you're saying is the second > thing, I don't see any reason to be less skeptical about that > claim than about the earlier claim about the C++ standard. Is > one of those two readings what you meant, or did were you trying > to say something else that didn't occur to me? We were originally discussing the C standard library, but the same does apply to the C++ standard library: it is simply a bigger and more complex requirement. So yes, I was effectively saying two. If you are skeptical about the claim that a competent C++ programmer could implement a part of the library (and by implication a competent C programmer could implement a part of the C library) you have a very dim view of your fellow professionals. I'll reiterate my claim: the C and C++ standard library specifications are specifications a competent programmer can use to write a conforming implementation. >>> I also have gone through the >>> exercise of reading an ISO C++ standard from cover to cover -- >>> not absorbing everything, just reading it once through. Based on >>> those experiences I believe the magnitude of the task is a bit >>> larger than you seem to expect. I hasten to add this means no >>> disrespect for your abilities, I believe it would be a daunting >>> task for pretty much anyone. >> >> In its entirety for on person yes, for a team, no. > > I think you're implying that understanding the whole can proceed > faster by breaking up the task into pieces and having different > people work on different parts independently. First off this > isn't what I was asking about (and I see now that I may have > misunderstood that you were answering a question different than > the one I asked), but even ignoring that, being able to go > faster in parallel assumes there is comparatively little > inter-dependence between different parts of the document. The same applies to any project of moderate or higher complexity. If aster in parallel were not faster, nothing would get written... > IME > both the C standard and the C++ standard have a fair amount of > inter-dependence, and different sections cannot be read > effectively in isolation. So I doubt there would be much > speedup. So you don't believe a team could implement the standard library faster than a individual? I find that hard to believe, unless you have never worked on a large project with good process, which I doubt. > I agree that parts of C++ can be understood and implemented > pretty much in isolation, eg, lots of the STL. On the other > hand those parts tend to be those least likely in need of > re-implementation, because they can be (almost completely) > implemented in the core language, and so would be portable > between different implementations. I understand that you > are optimistic about your abilities (or those of your team) > but I don't see any supporting reasoning to go with that - > just your claim that it wouldn't be that hard. Do you have > anything more to offer than just a claim about how easy > or difficult it would be? (To be clear, the "it" here means > becoming thoroughly familiar with the ISO C++ standard.) No, the ISO C++ standard is just another complex set of requirements. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-16 00:31 -0800 |
| Message-ID | <kfnlgubiexb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101675 |
Ian Collins <ian-news@hotmail.com> writes: > On 01/13/17 06:24 PM, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 01/ 3/17 12:04 AM, Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> On 12/29/16 10:34 PM, Tim Rentsch wrote: >>>>>> Ian Collins <ian-news@hotmail.com> writes: >>>>>> >>>>>>> On 12/28/16 10:55 AM, Robert Wessel wrote: >>>>>>>> [...] >>>>>>>> My point is that the OS writers will probably be better at >>>>>>>> implementing a given function to use the OS well, but are rather >>>>>>>> more likely to miss required subtleties of the C library as seen >>>>>>>> by the C programmer. >>>>>>> >>>>>>> Maybe, but what are the OS writers if not (very experienced) C >>>>>>> programmers? >>>>>> >>>>>> Being a very experienced C programmer is not the same as having >>>>>> an in-depth familiarity with the ISO C standard. Maybe they >>>>>> should be, but they aren't. Consider the reaction of the Linux >>>>>> development community to the so-called "strict aliasing" rules. >>>>>> >>>>>> For that matter, presumably you count yourself as an experienced >>>>>> C++ developer. Would you also say that you are thoroughly >>>>>> familiar with the ISO C++ standard? >>>>> >>>>> No I wouldn't say that I am thoroughly familiar with it. But a >>>>> standard is just another requirements document, so if I (or any other >>>>> experienced programmer) were tasked with implementing a part of it, I >>>>> very quickly would be. >>>> >>>> I hope you won't be offended if I say this doesn't convince >>>> me. I have gone through this process for the ISO C standard, and >>>> it has been a long process. >>> >>> A couple of points: >>> >>> I wasn't suggesting that one person would be implementing the entire >>> (I did say "part of it") standard library, it would be a team effort. >>> >>> As a specification, the library section of the standard is well >>> written. Quality wise, it is way ahead of many that I have had to work >>> from. If you remember a while back we had a thread here covering the >>> implementation of strtol() and friends which given the quality of the >>> specification was a straightforward task. >>> >>> In the case of POSIX (as originally discussed), the test suite is >>> already written. >> >> We have some topic skew here. My last comment was a response >> on a later topic, whereas your followup (mostly) presumes the >> context of an earlier topic. So even though your comments >> are relevant to some of the discussion up-thread, they don't >> really address the questions raised about your later comments. > > I'm not sure which specific comments you were referring to, but when I > say that a big part of every professional programmer's job is > interpreting often very complex specifications I'm sure you won't > disagree. I'm also pretty sure that you would agree with my > statements that the quality of the C (and C++) standard's requirements > for the library being better than most we have to deal with. > > So I don't see how you can claim that a programmer experienced in the > language, but not currently intimately familiar with the standard > would not be able to implement some (or all with sufficient time) of > the standard library. I mention the implementation of strtol() as a > concrete example which I believe strengthens my claim. > >>> When compared to many project specifications, it is on the small >>> side. The current project I am working on is in the order of 80 man >>> years of work. The specifications are large and complex and no where >>> near as detailed or stable as the standard library specification. >> >> I think you are saying one of two things here. Either: one, the >> large and complex specifications took a long time to master and >> understand; or two, the large and complex specifications were >> bigger and less well-written than the C++ standard, presumably >> also with just as much interdependency, yet they could be well >> understood fairly quickly (and so by implication the C++ standard >> could be understood at least that quickly). If what you're >> saying is the first thing, that seems consistent what what I said >> about the C++ standard. If what you're saying is the second >> thing, I don't see any reason to be less skeptical about that >> claim than about the earlier claim about the C++ standard. Is >> one of those two readings what you meant, or did were you trying >> to say something else that didn't occur to me? > > We were originally discussing the C standard library, but the same > does apply to the C++ standard library: it is simply a bigger and more > complex requirement. So yes, I was effectively saying two. If you > are skeptical about the claim that a competent C++ programmer could > implement a part of the library (and by implication a competent C > programmer could implement a part of the C library) you have a very > dim view of your fellow professionals. > > I'll reiterate my claim: the C and C++ standard library specifications > are specifications a competent programmer can use to write a > conforming implementation. We are still talking about different things, and apparently that is getting worse rather than better. I regret that topic skew has interfered with our having a more substantive discussion. >>>> I also have gone through the >>>> exercise of reading an ISO C++ standard from cover to cover -- >>>> not absorbing everything, just reading it once through. Based on >>>> those experiences I believe the magnitude of the task is a bit >>>> larger than you seem to expect. I hasten to add this means no >>>> disrespect for your abilities, I believe it would be a daunting >>>> task for pretty much anyone. >>> >>> In its entirety for on person yes, for a team, no. >> >> I think you're implying that understanding the whole can proceed >> faster by breaking up the task into pieces and having different >> people work on different parts independently. First off this >> isn't what I was asking about (and I see now that I may have >> misunderstood that you were answering a question different than >> the one I asked), but even ignoring that, being able to go >> faster in parallel assumes there is comparatively little >> inter-dependence between different parts of the document. > > The same applies to any project of moderate or higher complexity. If > aster in parallel were not faster, nothing would get written... > >> IME >> both the C standard and the C++ standard have a fair amount of >> inter-dependence, and different sections cannot be read >> effectively in isolation. So I doubt there would be much >> speedup. > > So you don't believe a team could implement the standard library > faster than a individual? I find that hard to believe, unless you > have never worked on a large project with good process, which I doubt. (Repeat of topic skew comment.) The point I was trying to address is not whether adding people would make things go faster, but _how much faster_ would it actually be? And again, I am NOT talking about the standard library. >> I agree that parts of C++ can be understood and implemented >> pretty much in isolation, eg, lots of the STL. On the other >> hand those parts tend to be those least likely in need of >> re-implementation, because they can be (almost completely) >> implemented in the core language, and so would be portable >> between different implementations. I understand that you >> are optimistic about your abilities (or those of your team) >> but I don't see any supporting reasoning to go with that - >> just your claim that it wouldn't be that hard. Do you have >> anything more to offer than just a claim about how easy >> or difficult it would be? (To be clear, the "it" here means >> becoming thoroughly familiar with the ISO C++ standard.) > > No, the ISO C++ standard is just another complex set of requirements. This comment strikes me as a bit glib. I'm not asking you to try to convince me, but unsupported assurances are not very reassuring.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-18 21:45 +1300 |
| Message-ID | <ee8o8fF2vaqU5@mid.individual.net> |
| In reply to | #101932 |
On 01/16/17 09:31 PM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 01/13/17 06:24 PM, Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >> >> I'll reiterate my claim: the C and C++ standard library specifications >> are specifications a competent programmer can use to write a >> conforming implementation. > > We are still talking about different things, and apparently that > is getting worse rather than better. I regret that topic > skew has interfered with our having a more substantive > discussion. That was not my intent. I thought to point of difference was whether an experienced programmer while not intimately familiar with the standard was competent to implement all or part of the standard library. >>> IME >>> both the C standard and the C++ standard have a fair amount of >>> inter-dependence, and different sections cannot be read >>> effectively in isolation. So I doubt there would be much >>> speedup. >> >> So you don't believe a team could implement the standard library >> faster than a individual? I find that hard to believe, unless you >> have never worked on a large project with good process, which I doubt. > > (Repeat of topic skew comment.) > > The point I was trying to address is not whether adding people > would make things go faster, but _how much faster_ would it > actually be? And again, I am NOT talking about the standard > library. If not the standard library, then what? >>> I agree that parts of C++ can be understood and implemented >>> pretty much in isolation, eg, lots of the STL. On the other >>> hand those parts tend to be those least likely in need of >>> re-implementation, because they can be (almost completely) >>> implemented in the core language, and so would be portable >>> between different implementations. I understand that you >>> are optimistic about your abilities (or those of your team) >>> but I don't see any supporting reasoning to go with that - >>> just your claim that it wouldn't be that hard. Do you have >>> anything more to offer than just a claim about how easy >>> or difficult it would be? (To be clear, the "it" here means >>> becoming thoroughly familiar with the ISO C++ standard.) >> >> No, the ISO C++ standard is just another complex set of requirements. > > This comment strikes me as a bit glib. I'm not asking you > to try to convince me, but unsupported assurances are not > very reassuring. I don't agree that it is glib. As professional programmers, we are given complex requirements to implement every day. What makes the C (or C++) standard special? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-30 18:24 -0800 |
| Message-ID | <kfn7f5cezkm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102103 |
(Pruning a fair bit as I don't have much response to give.) Ian Collins <ian-news@hotmail.com> writes: > On 01/16/17 09:31 PM, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 01/13/17 06:24 PM, Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >> >> We are still talking about different things, and apparently that >> is getting worse rather than better. I regret that topic >> skew has interfered with our having a more substantive >> discussion. > > That was not my intent. [...] Right, I didn't think it was, nor did I mean to imply so. >>> So you don't believe a team could implement the standard library >>> faster than a individual? [...] >> >> The point I was trying to address is not whether adding people >> would make things go faster, but _how much faster_ would it >> actually be? And again, I am NOT talking about the standard >> library. > > If not the standard library, then what? After seeing the topic skew increase I gave up trying to unwind it. Let's hope next time will be better. >>>> I agree that parts of C++ can be understood and implemented >>>> pretty much in isolation, eg, lots of the STL. On the other >>>> hand those parts tend to be those least likely in need of >>>> re-implementation, because they can be (almost completely) >>>> implemented in the core language, and so would be portable >>>> between different implementations. I understand that you >>>> are optimistic about your abilities (or those of your team) >>>> but I don't see any supporting reasoning to go with that - >>>> just your claim that it wouldn't be that hard. Do you have >>>> anything more to offer than just a claim about how easy >>>> or difficult it would be? (To be clear, the "it" here means >>>> becoming thoroughly familiar with the ISO C++ standard.) >>> >>> No, the ISO C++ standard is just another complex set of requirements. >> >> This comment strikes me as a bit glib. I'm not asking you >> to try to convince me, but unsupported assurances are not >> very reassuring. > > I don't agree that it is glib. As professional programmers, we are > given complex requirements to implement every day. What makes the C > (or C++) standard special? What makes your unsupported assertion not be glib?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-04 13:49 +1300 |
| Message-ID | <efkmpjFh1v7U5@mid.individual.net> |
| In reply to | #102817 |
On 01/31/17 03:24 PM, Tim Rentsch wrote: > (Pruning a fair bit as I don't have much response to give.) > > Ian Collins <ian-news@hotmail.com> writes: > >> On 01/16/17 09:31 PM, Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>> No, the ISO C++ standard is just another complex set of requirements. >>> >>> This comment strikes me as a bit glib. I'm not asking you >>> to try to convince me, but unsupported assurances are not >>> very reassuring. >> >> I don't agree that it is glib. As professional programmers, we are >> given complex requirements to implement every day. What makes the C >> (or C++) standard special? > > What makes your unsupported assertion not be glib? What justification do you offer to say that it is untrue? I ask again: what makes the C (or C++) standard special? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-10 01:57 -0800 |
| Message-ID | <kfna89u4bbz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103106 |
Ian Collins <ian-news@hotmail.com> writes:
> On 01/31/17 03:24 PM, Tim Rentsch wrote:
>> (Pruning a fair bit as I don't have much response to give.)
>>
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> On 01/16/17 09:31 PM, Tim Rentsch wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>>> No, the ISO C++ standard is just another complex set of requirements.
>>>>
>>>> This comment strikes me as a bit glib. I'm not asking you
>>>> to try to convince me, but unsupported assurances are not
>>>> very reassuring.
>>>
>>> I don't agree that it is glib. As professional programmers, we are
>>> given complex requirements to implement every day. What makes the C
>>> (or C++) standard special?
>>
>> What makes your unsupported assertion not be glib?
>
> What justification do you offer to say that it is untrue? I ask
> again: what makes the C (or C++) standard special?
Every so often I fall into a conversation that somehow winds its
way around to an exchange which might be characterized abstractly
as follows:
(other person): The Government is covering up evidence of
hundreds of UFO landings.
(me): Oh? What makes you think UFOs have landed?
(other person): Can you prove they haven't??
When I hear a response like this it's a pretty safe bet that the
conversation isn't going to go anywhere useful after that.
There is nothing wrong with you offering up any assertions you
like, including unsupported ones. For people listening, if an
assertion remains unsupported, there is also nothing wrong with a
reaction no different than if you had said UFOs have landed.
And that is all that I have been suggesting.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-10 10:32 +0000 |
| Message-ID | <o7k4nn$9vk$1@dont-email.me> |
| In reply to | #103598 |
On 10/02/17 09:57, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 01/31/17 03:24 PM, Tim Rentsch wrote: >>> (Pruning a fair bit as I don't have much response to give.) >>> >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 01/16/17 09:31 PM, Tim Rentsch wrote: >>>>> Ian Collins <ian-news@hotmail.com> writes: >>>>> >>>>>> No, the ISO C++ standard is just another complex set of requirements. >>>>> >>>>> This comment strikes me as a bit glib. I'm not asking you >>>>> to try to convince me, but unsupported assurances are not >>>>> very reassuring. >>>> >>>> I don't agree that it is glib. As professional programmers, we are >>>> given complex requirements to implement every day. What makes the C >>>> (or C++) standard special? >>> >>> What makes your unsupported assertion not be glib? >> >> What justification do you offer to say that it is untrue? I ask >> again: what makes the C (or C++) standard special? > > Every so often I fall into a conversation that somehow winds its > way around to an exchange which might be characterized abstractly > as follows: > > (other person): The Government is covering up evidence of > hundreds of UFO landings. > > (me): Oh? What makes you think UFOs have landed? > > (other person): Can you prove they haven't?? Yes. If it's landed, it's not a UFO. It's just a UO. > When I hear a response like this it's a pretty safe bet that the > conversation isn't going to go anywhere useful after that. I've found that the most time-effective way to deal with these people (if deal with them I must) is to point out that it's perfectly fine to have an unfalsifiable belief, but such beliefs are not scientific. If you want scientists to accept your claims, you have to be able to support them with verifiable evidence. To say "you can't prove I'm wrong" is insufficient. (As a Christian, I hold my own unfalsifiable beliefs, but I don't make the mistake of saying "I must be right because you can't prove I'm wrong".) To return from the general to the specific, however: in the current case, I think Ian's claim is broadly correct in all but one word: the word "just". Am I right in thinking that was the word you were objecting to when you called the statement 'glib'[1]? Clearly the C and C++ standards are both complex sets of requirements, but that's not all they are by any means. For a start, they are contracts, or protocols, or "deals" if you like, that make it possible for C (or C++) programmers and compiler writers to work together to produce real programs. [1] Try as I might, I couldn't make sense of that, until I eventually realised that you meant "glib", not "glib"! -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-13 08:44 -0800 |
| Message-ID | <kfntw7y11mt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103600 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 10/02/17 09:57, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 01/31/17 03:24 PM, Tim Rentsch wrote: >>>> (Pruning a fair bit as I don't have much response to give.) >>>> >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> On 01/16/17 09:31 PM, Tim Rentsch wrote: >>>>>> Ian Collins <ian-news@hotmail.com> writes: >>>>>> >>>>>>> No, the ISO C++ standard is just another complex set of requirements. >>>>>> >>>>>> This comment strikes me as a bit glib. I'm not asking you >>>>>> to try to convince me, but unsupported assurances are not >>>>>> very reassuring. >>>>> >>>>> I don't agree that it is glib. As professional programmers, we are >>>>> given complex requirements to implement every day. What makes the C >>>>> (or C++) standard special? >>>> >>>> What makes your unsupported assertion not be glib? >>> >>> What justification do you offer to say that it is untrue? I ask >>> again: what makes the C (or C++) standard special? >> >> Every so often I fall into a conversation that somehow winds its >> way around to an exchange which might be characterized abstractly >> as follows: >> >> (other person): The Government is covering up evidence of >> hundreds of UFO landings. >> >> (me): Oh? What makes you think UFOs have landed? >> >> (other person): Can you prove they haven't?? > > Yes. > > If it's landed, it's not a UFO. It's just a UO. This reminds me of a news story about a guy who reportedly had claimed he saw a UFO. But when he was interviewed about it, he said, "I didn't say it was a UFO. I didn't know *what* it was." >> When I hear a response like this it's a pretty safe bet that the >> conversation isn't going to go anywhere useful after that. > > I've found that the most time-effective way to deal with these people > (if deal with them I must) is to point out that it's perfectly fine to > have an unfalsifiable belief, but such beliefs are not scientific. If > you want scientists to accept your claims, you have to be able to > support them with verifiable evidence. To say "you can't prove I'm > wrong" is insufficient. (As a Christian, I hold my own unfalsifiable > beliefs, but I don't make the mistake of saying "I must be right > because you can't prove I'm wrong".) Yes, in retrospect I could have picked a better example, because I didn't mean for the question to be unfalsifiable, at least not in principle. It was just the first example that occurred to me after remembering the /real/ example that happened to me recently, which was even worse, it being a nebulous (and probably equally unfalsifiable) political statement. > To return from the general to the specific, however: in the current > case, I think Ian's claim is broadly correct in all but one word: the > word "just". Am I right in thinking that was the word you were > objecting to when you called the statement 'glib'[1]? Sort of, not exactly though. My objection was to the glossing over of several (and I'm not even sure how many) essential aspects, including: what counts as a complex requirements document; what evidence is there that other documents in this set are comprehensible; for that matter, what is the metric for being comprehensible; and most significantly, what support is there for the claim that the C/C++ standards are just as comprehensible as other members of the set? The combination of vagueness and lack of any sort of supporting statements is what prompted the "glib" appraisal. > Clearly the C and C++ standards are both complex sets of requirements, > but that's not all they are by any means. For a start, they are > contracts, or protocols, or "deals" if you like, that make it possible > for C (or C++) programmers and compiler writers to work together to > produce real programs. One way that the C and C++ standards documents differ from other requirements documents is the two standards documents are concerned with two different things, viz., implementations and programs, simultaneously giving constraints and relationships for both. (This may be the same as what you just said except in slightly different language.) That property is enough by itself to suspect a notable difference between the two standards and requirements documents that deal with only one principal entity. > [1] Try as I might, I couldn't make sense of that, until I eventually > realised that you meant "glib", not "glib"! Oh yes, I definitely meant "glib", and not "glib". (And you'll be pleased to know I puzzled over your statement for a moment, and then laughed out loud.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-02 10:42 -0800 |
| Message-ID | <06544819-1f87-4e1c-94ca-918f049d1d42@googlegroups.com> |
| In reply to | #100599 |
On Thursday, December 29, 2016 at 1:45:48 PM UTC-6, Ian Collins wrote: > No I wouldn't say that I am thoroughly familiar with it. But a standard > is just another requirements document, so if I (or any other experienced > programmer) were tasked with implementing a part of it, I very quickly > would be. The C89 Standard wasn't written to describe a new language, but rather a family of languages that were already in wide use. There would have been no way to write a single set of requirements, or even two sets of requirements, such that all useful implementations could comply with at least one set, and at least one set would be sufficient to meet the needs of all useful programs. Consequently, I don't think the C Standard can sensibly be viewed as "just another requirements document", as much as some people would try to view it that way. Such a view would simultaneously prevent the Standard from saying anything at all useful about low-end implementations for which meeting some of the requirements in the spec would be impractical, but also subject even programmers targeting high-end systems to the limitations of low-end systems upon which their programs would never be run anyway. If someone is seeking to write a useful quality implementation for a particular platform, I would consider the expectations of programmers who are targeting that platform as being far more important than what the Standard would say. If many programmers need features and guarantees which the Standard does not provide, but which existing implementations for that platform do, someone writing a quality implementation will not try to use the Standard as justification for withholding such features.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-02 13:06 -0800 |
| Message-ID | <lnd1g5w4se.fsf@kst-u.example.com> |
| In reply to | #100890 |
supercat@casperkitty.com writes:
[...]
> Consequently, I don't think the C Standard can sensibly be viewed as "just
> another requirements document", as much as some people would try to view
> it that way. Such a view would simultaneously prevent the Standard from
> saying anything at all useful about low-end implementations for which
> meeting some of the requirements in the spec would be impractical, but
> also subject even programmers targeting high-end systems to the limitations
> of low-end systems upon which their programs would never be run anyway.
The standard does not attempt to say anything useful about
implementations that don't conform to it.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-03 10:53 +1300 |
| Message-ID | <ed00e1Flsf9U2@mid.individual.net> |
| In reply to | #100890 |
On 01/ 3/17 07:42 AM, supercat@casperkitty.com wrote: > On Thursday, December 29, 2016 at 1:45:48 PM UTC-6, Ian Collins wrote: >> No I wouldn't say that I am thoroughly familiar with it. But a standard >> is just another requirements document, so if I (or any other experienced >> programmer) were tasked with implementing a part of it, I very quickly >> would be. > > The C89 Standard wasn't written to describe a new language, but rather a > family of languages that were already in wide use. There would have been > no way to write a single set of requirements, or even two sets of > requirements, such that all useful implementations could comply with at > least one set, and at least one set would be sufficient to meet the needs > of all useful programs. Well all Unix implementations manged quite well, didn't they? The POISX standard extends, defining the undefined, but does not contradict the C standard it is based upon. > Consequently, I don't think the C Standard can sensibly be viewed as "just > another requirements document", as much as some people would try to view > it that way. Such a view would simultaneously prevent the Standard from > saying anything at all useful about low-end implementations for which > meeting some of the requirements in the spec would be impractical, but > also subject even programmers targeting high-end systems to the limitations > of low-end systems upon which their programs would never be run anyway. Utter tripe. We are discussing the libraries section of the standard and libraries provide a common interface for both high and low end systems, which enables us to develop software on the former for the latter. It does not say anything about systems that are not intended to conform to it. > If someone is seeking to write a useful quality implementation for a > particular platform, I would consider the expectations of programmers who > are targeting that platform as being far more important than what the > Standard would say. Then your thinking is wrong headed. Do you understand why we have standards? > If many programmers need features and guarantees which > the Standard does not provide, but which existing implementations for that > platform do, someone writing a quality implementation will not try to use > the Standard as justification for withholding such features. I'm not aware of any that do, care to name some? -- Ian
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web