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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-02-03 20:40 +0100 |
| Message-ID | <o72mbt$1isr$1@gioia.aioe.org> |
| In reply to | #100199 |
On 12/24/2016 11:01 PM, BartC wrote: > On 24/12/2016 20:43, Ian Collins wrote: >> On 12/25/16 02:04 AM, BartC wrote: >>> On 24/12/2016 03:46, Ian Collins wrote: >>>> On 12/24/16 01:09 AM, BartC wrote: >>> >>>>> I don't know what else is needed to show that atoi() is an integral >>>>> part >>>>> of the language. Obviously there is a fundamental distinction between the language and the library, even if they are both part of the same standard (section 6 and 7 respectively) The language is defined by the syntactic and semantic rules that compose C code: lexical elements, expressions, declarations, statements etc. Again, all that is under section 6. This is the part that is actually processed by compilers. Which convert statements into machine code. This part does not include atoi() On the other hand, the standard library is a collection of facilities (macros and functions) which are meant to be /called/ by user code as opposed to /compiled/ into machine code. This part includes atoi() The fact that the language and the library are both part of the same standard, apart of being great for practical purposes, obviously does not make the two the same thing. As far as I can see, the distinction is not only theoretical, but it is also one of the components of the success of the language: it provides for excellent scalability, which explains why nowadays all major architectures support C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-29 13:47 -0800 |
| Message-ID | <kfno9zuv24t.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100134 |
BartC <bc@freeuk.com> writes:
> On 24/12/2016 03:46, Ian Collins wrote:
>> On 12/24/16 01:09 AM, BartC wrote:
>>
>>> I don't know what else is needed to show that atoi() is an integral part
>>> of the language.
>>
>> Unix systems have always had their own standard library implementations.
>
> Of what? The C library?
>
> If so, do they have standard library implementations for Cobol, Lisp
> and K too? Do they have matrix-multiplication routines for maths
> languages?
>
> I think there is too much cosiness between C and Unix, such that you
> can't tell what is part of the language and what is part of the
> OS. [...]
Telling the difference is easy. System calls are documented
in Section 2. C library functions are documented in Section 3.
https://en.wikipedia.org/wiki/Man_page#Manual_sections
Section 3 sometimes also has entries for other libraries besides
the C standard library, but typically they are marked with the
name of the library they go with.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 14:33 -0800 |
| Message-ID | <lntw9mz7pa.fsf@kst-u.example.com> |
| In reply to | #100506 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> BartC <bc@freeuk.com> writes:
>> On 24/12/2016 03:46, Ian Collins wrote:
>>> On 12/24/16 01:09 AM, BartC wrote:
>>>> I don't know what else is needed to show that atoi() is an integral part
>>>> of the language.
>>>
>>> Unix systems have always had their own standard library implementations.
>>
>> Of what? The C library?
>>
>> If so, do they have standard library implementations for Cobol, Lisp
>> and K too? Do they have matrix-multiplication routines for maths
>> languages?
>>
>> I think there is too much cosiness between C and Unix, such that you
>> can't tell what is part of the language and what is part of the
>> OS. [...]
>
> Telling the difference is easy. System calls are documented
> in Section 2. C library functions are documented in Section 3.
>
> https://en.wikipedia.org/wiki/Man_page#Manual_sections
>
> Section 3 sometimes also has entries for other libraries besides
> the C standard library, but typically they are marked with the
> name of the library they go with.
That's an implementation detail, and it's not 100% reliable. On Linux,
for example, time() is a system call, documented in section 2, but it's
also a standard C library function. The system call happens (not by
coincidence!) to match the requirements for the functoin.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 10:04 +0000 |
| Message-ID | <5868d412.2188062@news.xs4all.nl> |
| In reply to | #100506 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > BartC <bc@freeuk.com> writes: > > > I think there is too much cosiness between C and Unix, such that you > > can't tell what is part of the language and what is part of the > > OS. [...] > > Telling the difference is easy. System calls are documented > in Section 2. C library functions are documented in Section 3. It's much easier than that. If it's in the Standard it's part of C. If it's not in the Standard, it's not part of C. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 11:38 +0000 |
| Message-ID | <o4aplp$npv$1@dont-email.me> |
| In reply to | #100755 |
On 01/01/2017 10:04, Richard Bos wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> BartC <bc@freeuk.com> writes: >> >>> I think there is too much cosiness between C and Unix, such that you >>> can't tell what is part of the language and what is part of the >>> OS. [...] >> >> Telling the difference is easy. System calls are documented >> in Section 2. C library functions are documented in Section 3. > > It's much easier than that. > > If it's in the Standard it's part of C. If it's not in the Standard, > it's not part of C. /The C Programming Language/ by K&R, chapter 8: The *Unix* System Interface. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 13:49 +0000 |
| Message-ID | <58690881.208375@news.xs4all.nl> |
| In reply to | #100762 |
BartC <bc@freeuk.com> wrote: > On 01/01/2017 10:04, Richard Bos wrote: > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > >> BartC <bc@freeuk.com> writes: > >> > >>> I think there is too much cosiness between C and Unix, such that you > >>> can't tell what is part of the language and what is part of the > >>> OS. [...] > >> > >> Telling the difference is easy. System calls are documented > >> in Section 2. C library functions are documented in Section 3. > > > > It's much easier than that. > > > > If it's in the Standard it's part of C. If it's not in the Standard, > > it's not part of C. > > /The C Programming Language/ by K&R, chapter 8: The *Unix* System Interface. Which is not the Standard, and never pretended to be, but a textbook where the Unix SI is used as an example. This is clearly explained in the very first paragraph of the chapter, which you evidently preferred not to read, or to ignore for the sake of the lie. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:17 -0800 |
| Message-ID | <kfn8tqtu5o7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100755 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> BartC <bc@freeuk.com> writes: >> >>> I think there is too much cosiness between C and Unix, such that you >>> can't tell what is part of the language and what is part of the >>> OS. [...] >> >> Telling the difference is easy. System calls are documented >> in Section 2. C library functions are documented in Section 3. > > It's much easier than that. > > If it's in the Standard it's part of C. If it's not in the Standard, > it's not part of C. For day-to-day coding, I still find man pages to be the best first line of defense. I grant you the Standard is more complete and more definitive (ie, for functions that are part of the language definition rather than another library or the OS).
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-01-03 13:26 +0000 |
| Message-ID | <o4g8qv$90u$1@news.xmission.com> |
| In reply to | #100755 |
In article <5868d412.2188062@news.xs4all.nl>,
Richard Bos <rlbos@xs4all.nl> mechanically wrote:
>Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> BartC <bc@freeuk.com> writes:
>>
>> > I think there is too much cosiness between C and Unix, such that you
>> > can't tell what is part of the language and what is part of the
>> > OS. [...]
>>
>> Telling the difference is easy. System calls are documented
>> in Section 2. C library functions are documented in Section 3.
>
>It's much easier than that.
>
>If it's in the Standard it's part of C. If it's not in the Standard,
>it's not part of C.
Thank you, Kiki!
>Richard
Oh, it's somebody else - playing at being Keith.
--
I'm becoming more and more convinced that both of the following are true:
1) Donald Trump is a DNC plot to destroy the GOP - and it has succeeded admirably.
2) Bernie Sanders is an RNC plot to destroy the Democratic Party.
Let's hope Bernie does not succeed as well as Donald already has.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-26 17:29 -0600 |
| Message-ID | <dq936cdvrevlrvl0hji1qsrkc5mbeeu89g@4ax.com> |
| In reply to | #100106 |
On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/24/16 01:09 AM, BartC wrote: >> On 23/12/2016 11:26, Richard Heathfield wrote: >>> On 23/12/16 11:08, BartC wrote: >>>> On 23/12/2016 06:56, Ike Naar wrote: >>> >>> <snip> >>> >>>>> The atoi function is not part of gcc, >>>>> it's part of the C runtime library (glibc, if you use GNU). >>>>> >>>> >>>> I've got a directory which appears to be the source code for gcc, or a >>>> version of it. >>>> >>>> Do you mean that, despite the 52,000 .c and .h files, it still doesn't >>>> include sources for the C libraries? >>> >>> Yes, he means that the source code for one program doesn't appear within >>> the source code for another program. So what? Do you include all the >>> source for all your programs within all your other programs? >> >> If my program was a language implementation and this was a part of the >> standard library for the language, then yes I would (and have done). >> >> I wouldn't if such a function was clearly part of an external library or >> part of the OS. >> >> In this case, atoi() is mentioned in the C standard, it's declared in >> the standard headers (stdlib.h) and it's mentioned in multiple places in >> K&R. >> >> I don't know what else is needed to show that atoi() is an integral part >> of the language. > >Unix systems have always had their own standard library implementations. > >Who is better qualified to write the code that interfaces with and must >be aware of the behaviour of the OS, the OS writers, or compiler writers? The flip side of that argument is "who is better qualified to write the code that performs actions expected by the language user?" I've seen plenty of cases where code is written to perform what the authors would *like* to be the requirement. So you really need someone who's firmly in both camps.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-27 10:10 -0800 |
| Message-ID | <4e4e0e9f-3a50-4bfd-80cc-0a375f2480a4@googlegroups.com> |
| In reply to | #100316 |
On Monday, December 26, 2016 at 5:29:58 PM UTC-6, robert...@yahoo.com wrote:
> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins wrote:
> >Who is better qualified to write the code that interfaces with and must
> >be aware of the behaviour of the OS, the OS writers, or compiler writers?
>
> The flip side of that argument is "who is better qualified to write
> the code that performs actions expected by the language user?" I've
> seen plenty of cases where code is written to perform what the authors
> would *like* to be the requirement. So you really need someone who's
> firmly in both camps.
If an OS documents the functions that perform various tasks, a quality
compiler for that OS should supply a library of functions or intrinsics
which, when invoked, will behave as calls to the appropriate OS functions.
For example, a compiler for the classic Macintosh would be expected to,
if code includes suitable header files, provide a function declaration
DateTimeRec *SecondsToDate(long s, DateTimeRec *d);
along with a function which would load register R0 with s, load register
A0 with the address in d, invoke the A-line trap associated with that
OS function, and then return the address in register A0.
Things are sometimes a bit less clear with regard to C's I/O functions.
For example, since the classic Macintosh uses bare carriage returns as its
normal line endings, a program which is supposed to produce a text file
with the two lines "HELLO" and "THERE" would need to output "HELLO\rTHERE"
but the standard way of producing such a file in C would be to output the
string "HELLO\nTHERE". If one were using an OS function to write the file,
there would be no question about how one should do it--write the bytes in
"HELLO\rTHERE". In C, however, it's less clear what should be written by
fprintf(f, "THIS\rIS\nA\r\nTEST\n\r1234"); or how those bytes should appear
when read back.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 08:33 +1300 |
| Message-ID | <ecftvcFi8sgU1@mid.individual.net> |
| In reply to | #100316 |
On 12/27/16 12:29 PM, Robert Wessel wrote: > On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> >> Unix systems have always had their own standard library implementations. >> >> Who is better qualified to write the code that interfaces with and must >> be aware of the behaviour of the OS, the OS writers, or compiler writers? > > > The flip side of that argument is "who is better qualified to write > the code that performs actions expected by the language user?" I've > seen plenty of cases where code is written to perform what the authors > would *like* to be the requirement. So you really need someone who's > firmly in both camps. The behaviour of the standard library functions is defined by the C standard, so no specialist knowledge is required to implement them. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-27 20:22 +0000 |
| Message-ID | <5862cd38.11595765@news.xs4all.nl> |
| In reply to | #100346 |
Ian Collins <ian-news@hotmail.com> wrote: > On 12/27/16 12:29 PM, Robert Wessel wrote: > > On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> > > > >> Unix systems have always had their own standard library implementations. > >> > >> Who is better qualified to write the code that interfaces with and must > >> be aware of the behaviour of the OS, the OS writers, or compiler writers? > > > > The flip side of that argument is "who is better qualified to write > > the code that performs actions expected by the language user?" I've > > seen plenty of cases where code is written to perform what the authors > > would *like* to be the requirement. So you really need someone who's > > firmly in both camps. > > The behaviour of the standard library functions is defined by the C > standard, so no specialist knowledge is required to implement them. Quite the contrary. For several (many?) Standard library functions, OS-specific knowledge is critical to implement them; for more, to implement them efficiently. That's _why_ they're in the Standard and not in a user library. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 10:18 +1300 |
| Message-ID | <ecg458Fi8sgU2@mid.individual.net> |
| In reply to | #100353 |
On 12/28/16 09:22 AM, Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> On 12/27/16 12:29 PM, Robert Wessel wrote: >>> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> >>> >>>> Unix systems have always had their own standard library implementations. >>>> >>>> Who is better qualified to write the code that interfaces with and must >>>> be aware of the behaviour of the OS, the OS writers, or compiler writers? >>> >>> The flip side of that argument is "who is better qualified to write >>> the code that performs actions expected by the language user?" I've >>> seen plenty of cases where code is written to perform what the authors >>> would *like* to be the requirement. So you really need someone who's >>> firmly in both camps. >> >> The behaviour of the standard library functions is defined by the C >> standard, so no specialist knowledge is required to implement them. > > Quite the contrary. For several (many?) Standard library functions, > OS-specific knowledge is critical to implement them; for more, to > implement them efficiently. That's _why_ they're in the Standard and not > in a user library. Isn't that what I originally said? My last reply wasn't well worded. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-27 13:28 -0800 |
| Message-ID | <f4af6e96-7148-4f8e-a0b7-b3f89a16e00d@googlegroups.com> |
| In reply to | #100358 |
On Tuesday, December 27, 2016 at 9:18:44 PM UTC, Ian Collins wrote: > On 12/28/16 09:22 AM, Richard Bos wrote: > > Ian Collins <ian-news@hotmail.com> wrote: > > > >> On 12/27/16 12:29 PM, Robert Wessel wrote: > >>> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> > >>> > >>>> Unix systems have always had their own standard library implementations. > >>>> > >>>> Who is better qualified to write the code that interfaces with and must > >>>> be aware of the behaviour of the OS, the OS writers, or compiler writers? > >>> > >>> The flip side of that argument is "who is better qualified to write > >>> the code that performs actions expected by the language user?" I've > >>> seen plenty of cases where code is written to perform what the authors > >>> would *like* to be the requirement. So you really need someone who's > >>> firmly in both camps. > >> > >> The behaviour of the standard library functions is defined by the C > >> standard, so no specialist knowledge is required to implement them. > > > > Quite the contrary. For several (many?) Standard library functions, > > OS-specific knowledge is critical to implement them; for more, to > > implement them efficiently. That's _why_ they're in the Standard and not > > in a user library. > > Isn't that what I originally said? My last reply wasn't well worded. > Technically you can buy your copy of Basic Algorithms, which has an implementation of the math library, and you've done it. In reality the book contains one example of a "real" implementation to show that to get performance and accuracy, you do need quite a bit of knowledge of floating point, the processor, and mathematics. However the simple routines get you started.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-27 15:55 -0600 |
| Message-ID | <pdo56cpl0bel2dd0sajiqiroocedm0uagl@4ax.com> |
| In reply to | #100346 |
On Wed, 28 Dec 2016 08:33:00 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/27/16 12:29 PM, Robert Wessel wrote: >> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> >>> Unix systems have always had their own standard library implementations. >>> >>> Who is better qualified to write the code that interfaces with and must >>> be aware of the behaviour of the OS, the OS writers, or compiler writers? >> >> >> The flip side of that argument is "who is better qualified to write >> the code that performs actions expected by the language user?" I've >> seen plenty of cases where code is written to perform what the authors >> would *like* to be the requirement. So you really need someone who's >> firmly in both camps. > >The behaviour of the standard library functions is defined by the C >standard, so no specialist knowledge is required to implement them. The knowledge and understanding of the C standard *are* specialist knowledge. It is very easy for someone new to the C standard to miss the many subtleties just from reading the standard. 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. The C developers are like to have the reverse problem.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 11:01 +1300 |
| Message-ID | <ecg6mbFi8shU1@mid.individual.net> |
| In reply to | #100362 |
On 12/28/16 10:55 AM, Robert Wessel wrote: > On Wed, 28 Dec 2016 08:33:00 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 12/27/16 12:29 PM, Robert Wessel wrote: >>> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> >>> wrote: >>> >>>> >>>> Unix systems have always had their own standard library implementations. >>>> >>>> Who is better qualified to write the code that interfaces with and must >>>> be aware of the behaviour of the OS, the OS writers, or compiler writers? >>> >>> >>> The flip side of that argument is "who is better qualified to write >>> the code that performs actions expected by the language user?" I've >>> seen plenty of cases where code is written to perform what the authors >>> would *like* to be the requirement. So you really need someone who's >>> firmly in both camps. >> >> The behaviour of the standard library functions is defined by the C >> standard, so no specialist knowledge is required to implement them. > > > The knowledge and understanding of the C standard *are* specialist > knowledge. It is very easy for someone new to the C standard to miss > the many subtleties just from reading the standard. > > 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? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-27 16:40 -0600 |
| Message-ID | <hdq56c16f29qv6qblv2b3u0kdlst80qfji@4ax.com> |
| In reply to | #100363 |
On Wed, 28 Dec 2016 11:01:46 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/28/16 10:55 AM, Robert Wessel wrote: >> On Wed, 28 Dec 2016 08:33:00 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> On 12/27/16 12:29 PM, Robert Wessel wrote: >>>> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> >>>> wrote: >>>> >>>>> >>>>> Unix systems have always had their own standard library implementations. >>>>> >>>>> Who is better qualified to write the code that interfaces with and must >>>>> be aware of the behaviour of the OS, the OS writers, or compiler writers? >>>> >>>> >>>> The flip side of that argument is "who is better qualified to write >>>> the code that performs actions expected by the language user?" I've >>>> seen plenty of cases where code is written to perform what the authors >>>> would *like* to be the requirement. So you really need someone who's >>>> firmly in both camps. >>> >>> The behaviour of the standard library functions is defined by the C >>> standard, so no specialist knowledge is required to implement them. >> >> >> The knowledge and understanding of the C standard *are* specialist >> knowledge. It is very easy for someone new to the C standard to miss >> the many subtleties just from reading the standard. >> >> 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? Were we discussing situations specifically related to OS's written in C? zOS, for example, has more than a few quirks in its implementation of "open" functionality. You should see some of the howlers that have been (and still are) in the TCP stack*. In any event, I'd say that merely being a very experienced user of something, is not quite sufficient to be a good *implementer*. Although it certainly can't hurt. *For example, there's an important bit of TCP support in CICS that makes a major (incorrect) assumption about the (lack of) segmentation of the beginning of a connected stream. IOW, it expects the first recv() to always retrieve all of the data sent by the client with its first send(). There are significant limitations on the length of that first string (about 50 bytes), and so it ought to be OK on all actual implementations, but it's certainly not required.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 11:53 +1300 |
| Message-ID | <ecg9mvFi8shU4@mid.individual.net> |
| In reply to | #100368 |
On 12/28/16 11:40 AM, Robert Wessel wrote: > On Wed, 28 Dec 2016 11:01:46 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 12/28/16 10:55 AM, Robert Wessel wrote: >>> On Wed, 28 Dec 2016 08:33:00 +1300, Ian Collins <ian-news@hotmail.com> >>> wrote: >>> >>>> On 12/27/16 12:29 PM, Robert Wessel wrote: >>>>> On Sat, 24 Dec 2016 16:46:38 +1300, Ian Collins <ian-news@hotmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Unix systems have always had their own standard library implementations. >>>>>> >>>>>> Who is better qualified to write the code that interfaces with and must >>>>>> be aware of the behaviour of the OS, the OS writers, or compiler writers? >>>>> >>>>> >>>>> The flip side of that argument is "who is better qualified to write >>>>> the code that performs actions expected by the language user?" I've >>>>> seen plenty of cases where code is written to perform what the authors >>>>> would *like* to be the requirement. So you really need someone who's >>>>> firmly in both camps. >>>> >>>> The behaviour of the standard library functions is defined by the C >>>> standard, so no specialist knowledge is required to implement them. >>> >>> >>> The knowledge and understanding of the C standard *are* specialist >>> knowledge. It is very easy for someone new to the C standard to miss >>> the many subtleties just from reading the standard. >>> >>> 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? > > > Were we discussing situations specifically related to OS's written in > C? "Unix systems have always had their own standard library implementations." <snip> > In any event, I'd say that merely being a very experienced user of > something, is not quite sufficient to be a good *implementer*. > Although it certainly can't hurt. Not to mention the test suites that have to be passed to gain UNIX certification! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-29 01:34 -0800 |
| Message-ID | <kfninq3w01w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100363 |
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? (The question meant in the generic, not necessarily about you specifically.) Based on the discussions I've in comp.lang.c++ recently, ISTM that very few have a real in-depth knowledge of the C++ standard, even among the more experienced with using C++. (And just to be clear, no slight intended - the C++ standard is a much more imposing document than the ISO C standard.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 06:27 -0800 |
| Message-ID | <10dd53ba-9a58-4f00-9c20-ff7904f52c39@googlegroups.com> |
| In reply to | #100562 |
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. The C Standard makes no attempt to mandate that implementations provide all of the features necessary for system programming. It is entirely possible to have an implementation which would be 100% conforming and yet be totally unsuitable for that purpose. What annoys Linux programmers is the attitude of some compiler writers that any code which relies upon behaviors not mandated by the Standard is "broken" rather than recognizing that quality implementations that are designed to be suitable for systems programming must allow programmers to access the necessary semantics without jumping through absurd hoops; an implementation which would require jumping through absurd hoops is not a quality implementation for such purposes.
[toc] | [prev] | [next] | [standalone]
Page 2 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