Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #70020 > unrolled thread
| Started by | Lynn McGuire <lmc@winsim.com> |
|---|---|
| First post | 2015-09-08 21:08 -0500 |
| Last post | 2015-09-11 12:14 -0700 |
| Articles | 20 on this page of 282 — 37 participants |
Back to article view | Back to comp.lang.c
"Know Your Language: C Rules Everything Around Me (Part One)" Lynn McGuire <lmc@winsim.com> - 2015-09-08 21:08 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 00:16 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 12:04 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 04:24 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 17:39 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-09 11:01 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 19:37 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-09 20:13 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-09 19:51 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 22:07 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-09 20:02 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 16:13 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-10 00:46 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-09 17:20 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 17:49 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-10 12:54 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 18:15 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-09 21:13 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-10 16:30 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-10 07:13 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-10 07:05 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-10 10:40 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-10 10:27 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 02:30 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-10 11:42 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 03:44 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" August Karlstrom <fusionfile@gmail.com> - 2015-09-10 17:42 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-15 20:17 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-15 17:08 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 03:32 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-15 20:46 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 08:51 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" August Karlstrom <fusionfile@gmail.com> - 2015-09-17 11:04 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-21 13:21 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" August Karlstrom <fusionfile@gmail.com> - 2015-09-27 20:21 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" raltbos@xs4all.nl (Richard Bos) - 2015-09-10 11:26 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 05:13 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-10 13:23 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 05:34 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-10 13:46 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-10 16:17 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-10 22:52 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-11 12:17 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-11 15:59 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-11 10:01 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jadill33@gmail.com - 2015-09-11 08:48 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-11 17:20 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jadill33@gmail.com - 2015-09-11 10:40 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-11 11:14 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Gareth Owen <gwowen@gmail.com> - 2015-09-12 06:46 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-11 08:59 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-11 11:23 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-11 18:40 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-11 22:44 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Gareth Owen <gwowen@gmail.com> - 2015-09-12 06:54 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-11 23:13 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-12 15:16 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-12 17:51 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-13 17:01 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-11 18:18 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-12 15:28 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-12 16:00 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-13 23:07 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-13 16:56 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Richard Heathfield <rjh@cpax.org.uk> - 2015-09-14 01:08 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-14 10:31 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 03:56 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-14 14:31 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 05:49 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 01:55 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 13:23 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 11:35 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-14 14:04 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-15 10:22 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-14 13:07 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-14 13:23 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 06:32 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 16:44 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-14 18:25 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 21:48 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-14 21:23 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-15 09:07 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-15 11:40 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-15 13:32 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-15 14:13 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-15 15:53 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-15 18:22 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-15 22:13 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 00:55 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 03:51 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 10:34 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 12:43 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 13:12 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 14:46 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 17:26 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-16 17:35 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 10:48 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 19:53 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 12:28 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-16 19:35 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 13:11 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-16 21:59 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" "Charles Richmond" <numerist@aquaporin4.com> - 2015-09-17 01:12 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 21:11 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 13:53 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 23:07 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 23:10 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 10:26 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 22:59 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-16 13:15 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 08:35 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-16 15:40 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 11:16 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 10:38 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 09:17 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 11:08 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 11:52 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 12:33 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 12:55 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 13:20 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 14:32 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-17 22:52 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 16:47 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-18 10:00 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-18 11:14 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" wssimms@gmail.com - 2015-09-18 19:47 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" wssimms@gmail.com - 2015-09-18 19:56 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-19 03:57 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" raltbos@xs4all.nl (Richard Bos) - 2015-09-23 12:32 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 18:28 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 16:32 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-16 11:03 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 08:42 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 22:53 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-16 22:23 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-16 15:34 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-16 16:07 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 11:20 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-16 16:44 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:18 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-17 00:45 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 12:02 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-17 01:17 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-16 17:24 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 14:23 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 11:27 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-17 12:07 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-17 23:10 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 08:40 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 09:02 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 10:44 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-18 13:13 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 22:39 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-18 09:03 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 16:46 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-27 08:13 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 10:12 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 14:03 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 05:23 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 15:12 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 11:16 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 11:53 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-09-20 15:00 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 18:23 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 01:23 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 08:58 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-17 16:14 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 09:34 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 12:32 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 03:54 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-17 14:09 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-17 12:17 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-17 10:12 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-17 19:41 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-17 21:10 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-17 20:19 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-17 21:44 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-17 13:46 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-18 14:00 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-18 06:19 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-18 08:25 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 13:58 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-17 10:48 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" raltbos@xs4all.nl (Richard Bos) - 2015-09-23 15:09 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Keith Thompson <kst-u@mib.org> - 2015-09-23 09:00 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 12:34 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 13:32 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-16 15:01 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 02:15 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Rosario19 <Ros@invalid.invalid> - 2015-09-16 09:15 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Rosario19 <Ros@invalid.invalid> - 2015-09-16 10:04 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-16 10:59 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 11:29 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-14 11:27 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-20 16:06 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-20 20:06 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-25 02:09 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-25 08:42 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-25 20:06 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-25 13:05 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-26 00:35 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-26 13:10 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-14 18:44 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-14 12:08 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 21:17 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-15 10:41 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-15 12:16 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 18:38 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-13 18:34 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 13:49 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-13 19:12 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 14:31 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 01:40 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 20:52 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 03:30 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Melzzzzz <mel@zzzzz.com> - 2015-09-14 05:03 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" jt@toerring.de (Jens Thoms Toerring) - 2015-09-14 09:32 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Melzzzzz <mel@zzzzz.com> - 2015-09-14 04:50 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Melzzzzz <mel@zzzzz.com> - 2015-09-14 04:42 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-14 10:43 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-11 19:30 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-11 23:58 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-11 17:54 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-12 11:52 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-12 17:58 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-12 21:09 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" <npnth@number18.invalid.invalid> - 2015-09-12 22:04 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-13 00:29 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-13 07:43 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-13 12:52 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-13 18:27 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-13 22:33 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-13 22:28 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 00:08 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-14 00:25 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-14 02:16 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 13:27 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Michael Forsythe <forsythe@example.com> - 2015-09-14 03:08 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-14 01:00 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-14 07:19 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" supercat@casperkitty.com - 2015-09-14 11:15 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-14 11:31 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Thompson <dave.thompson2@verizon.net> - 2015-09-20 18:35 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-12 15:38 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-13 08:38 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Brown <david.brown@hesbynett.no> - 2015-09-13 23:37 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-14 09:48 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-12 12:44 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-12 14:32 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-12 10:40 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-12 08:41 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-11 16:59 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-09-10 20:28 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" David Thompson <dave.thompson2@verizon.net> - 2015-09-20 18:35 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-12 05:04 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" James Kuyper <jameskuyper@verizon.net> - 2015-09-10 13:43 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ian Collins <ian-news@hotmail.com> - 2015-09-11 08:52 +1200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" bartekltg <bartekltg@gmail.com> - 2015-09-10 14:51 +0200
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-10 23:12 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Bartc <bc@freeuk.com> - 2015-09-10 14:29 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-10 17:20 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" wssimms@gmail.com - 2015-09-09 07:32 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" fir <profesor.fir@gmail.com> - 2015-09-09 08:15 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 12:00 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-09 04:20 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-09 08:52 -0600
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-09 15:53 +0000
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Lynn McGuire <lmc@winsim.com> - 2015-09-09 14:46 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:38 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-10 01:04 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-09 22:38 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" James Kuyper <jameskuyper@verizon.net> - 2015-09-10 00:23 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 02:34 -0700
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-10 17:51 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" James Kuyper <jameskuyper@verizon.net> - 2015-09-10 19:09 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-11 02:18 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Les Cargill <lcargill99@comcast.com> - 2015-09-10 21:01 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" James Kuyper <jameskuyper@verizon.net> - 2015-09-10 22:53 -0400
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-10 21:47 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-10 17:06 +0100
Re: "Know Your Language: C Rules Everything Around Me (Part One)" BGB <cr88192@hotmail.com> - 2015-09-10 10:22 -0500
Re: "Know Your Language: C Rules Everything Around Me (Part One)" Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 12:14 -0700
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-17 14:32 -0700 |
| Message-ID | <0d308dab-9574-4953-abec-542839045576@googlegroups.com> |
| In reply to | #70851 |
On Thursday, September 17, 2015 at 3:20:19 PM UTC-5, Keith Thompson wrote:
> Assuming that's correct, a program that depends on one output or the
> other is depending on unspecified behavior. I don't think there's been
> a significant change in this area from C90 to C99, or from C99 to C11.
I do not think it's unreasonable for a program to expect that a system with
even-remotely-decent floating-point semantics, use of "sprintf" to format two
identical floating-point variables will yield the same string.
Consider also something like:
void blah(double q)
{
char st[32];
double d=8888.15589;
sprintf(st, "%20.15f", d);
d+=q;
if (st[12] == '9')
printf("%20.15f nines", d);
else
printf("%20.15f zeroes", d);
}
A compiler which knows how "sprintf" works will be able to optimize away
the "if" statement and one of the "printf" calls, but I would posit that
it should at minimum be considered highly undesirable for blah(0.0) to
output the word "nines" after a bunch of zeroes, or "zeroes" after a bunch
of nines. For a compiler which tracks constants to optimize sprintf calls
is a useful and not overly difficult optimization, but it requires that the
compiler have access to a set of printf functions that work exactly the
same as those that will be used at runtime.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-17 22:52 +0000 |
| Message-ID | <mtfg7f$t62$1@speranza.aioe.org> |
| In reply to | #70855 |
supercat@casperkitty.com wrote: (snip) > I do not think it's unreasonable for a program to expect that a system with > even-remotely-decent floating-point semantics, use of "sprintf" to format > two identical floating-point variables will yield the same string. I suppose, but the other way around is less obvious. The compile time conversion of characters to internal floating point values is, often enough, different from the run-time conversion. If the C library is supplied from a different source than the compiler, that can easily happen. In the sprintf case, I wonder about: sprintf(s, "%.20f", 123.456789); which a compiler could evaluate as a compile time constant. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-17 16:47 -0700 |
| Message-ID | <lny4g4ehhm.fsf@kst-u.example.com> |
| In reply to | #70855 |
supercat@casperkitty.com writes:
> On Thursday, September 17, 2015 at 3:20:19 PM UTC-5, Keith Thompson wrote:
>> Assuming that's correct, a program that depends on one output or the
>> other is depending on unspecified behavior. I don't think there's been
>> a significant change in this area from C90 to C99, or from C99 to C11.
>
> I do not think it's unreasonable for a program to expect that a system with
> even-remotely-decent floating-point semantics, use of "sprintf" to format two
> identical floating-point variables will yield the same string.
Ok. Have you actually encountered this problem, or is it
hypothetical?
Upthread, you were talking about the problem of supporting both C99
and C11. The example we're now discussing doesn't seem relevant
to that. You were also making some point about which component
(compiler, run-time library, OS?) should be responsible for the
behavior of printf. The only relevant issue I can see is that it
affects whom you should complain to if something doesn't work the way
you expect -- that, and the possibility that you migth not be able to
switch to an implementation that's to you're liking quite as easily.
I'd say all of this is outside the scope of what the C standard
can reasonably specify.
> Consider also something like:
>
> void blah(double q)
> {
> char st[32];
> double d=8888.15589;
> sprintf(st, "%20.15f", d);
> d+=q;
> if (st[12] == '9')
> printf("%20.15f nines", d);
> else
> printf("%20.15f zeroes", d);
> }
>
> A compiler which knows how "sprintf" works will be able to optimize away
> the "if" statement and one of the "printf" calls, but I would posit that
> it should at minimum be considered highly undesirable for blah(0.0) to
> output the word "nines" after a bunch of zeroes, or "zeroes" after a bunch
> of nines. For a compiler which tracks constants to optimize sprintf calls
> is a useful and not overly difficult optimization, but it requires that the
> compiler have access to a set of printf functions that work exactly the
> same as those that will be used at runtime.
I suspect that emulating the behavior of sprintf at compile time
for optimization purposes probably isn't worth the effort. As far
as I can see, such an optimization would be useful only for code
specifically like yours, and I just don't see it being common enough
to be worthwhile.
And if different sprintf implementations actually do vary in their
behavior, then a compiler *can't* do that kind of optimization
(unless it can assume that it will always be used with a library
that behaves in a particular way).
If you're arguing that the output generated by printf for
floating-point values should be consistent across implementations,
that's a reasonable argument -- though it's complicated by the fact
that different systems can still have different floating-point
representations. IEEE hasn't *quite* conquered the world yet.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-18 10:00 -0700 |
| Message-ID | <fe84b201-e0e5-46d5-b423-ba3176b79d89@googlegroups.com> |
| In reply to | #70858 |
On Thursday, September 17, 2015 at 6:47:23 PM UTC-5, Keith Thompson wrote:
> Ok. Have you actually encountered this problem, or is it
> hypothetical?
I'm sorry I'm not very good at formulating examples. I have seen some
embedded compilers which will examine printf calls and replace them with
equivalent code which avoids the printf function, so that given e.g.
printf("The coordinates are %d,%d\n", x,y);
it would produce code equivalent to
puts_no_lf("The coordinates are ");
put_int(x);
putch(',');
put_int(y);
putch(10);
While that might be a little larger than the code required to call printf,
such substitutions will generally allow the printf function to be eliminated
entirely. Of course, such substitutions are only legitimate if they would
produce the same output as printf.
The above approach doesn't work superbly well in cases with the normal
compile-link approach, but an embedded compiler which takes all the C files
and produces an executable can observe which aspects of printf are actually
used and include just those in the output file. Another variation is to
have each compiler generate a weakly-linked version of "printf" which will
satisfy its needs, and prioritize them such that the most advanced version
of printf that is required will get built into an executable. That only
works if printf features are ranked, but can still offer some pretty big
advantages if most programs use the cheaper versions. As noted, though,
the substitution requires that the compiler achieve consistent behaviors
among all forms of printf that it uses.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-18 11:14 -0700 |
| Message-ID | <lnh9mregrm.fsf@kst-u.example.com> |
| In reply to | #70897 |
supercat@casperkitty.com writes:
> On Thursday, September 17, 2015 at 6:47:23 PM UTC-5, Keith Thompson wrote:
>> Ok. Have you actually encountered this problem, or is it
>> hypothetical?
>
> I'm sorry I'm not very good at formulating examples. I have seen some
> embedded compilers which will examine printf calls and replace them with
> equivalent code which avoids the printf function, so that given e.g.
>
> printf("The coordinates are %d,%d\n", x,y);
>
> it would produce code equivalent to
>
> puts_no_lf("The coordinates are ");
> put_int(x);
> putch(',');
> put_int(y);
> putch(10);
But the behavior of printf is well defined in that particular case, and
assuming puts_no_lf, put_int, and putch behave in the obvious manner,
the transformation won't cause any changes in behavior.
A simpler example: gcc will transform
printf("hello\n");
to
puts("hello");
But again, this does not cause a change in behavior. (Unless you
somehow replace printf and/or puts with your own versions, but that has
undefined behavior.)
There are (probably) cases involving floating-point output where the
result is unspecified. I don't believe gcc replaces it with other calls
in such cases. A quick experiment shows that it doesn't even replace
printf("%d\n", 42);
by
puts("42");
which would be a perfectly valid optimization.
Yes, there are cases where the output produced by printf is unspecified.
And yes, in principle, a compiler *could* optimize such a printf call to
something that doesn't produce the same output, as long as it's within
the set of permitted outputs. But in practice, I don't think any
compilers actually perform such optimizations. Replacing printf by puts
in very simple cases is worthwhile, but given that performing the
physical output is likely to be far more expensive than parsing the
format string, more sophisticated optimizations probably aren't
worth performing (or worrying about).
If a given printf call has unspecified output, a program that depends on
one particular output is arguably broken anyway, and vulnerable to
failing if the next release of the library happens to change the
behavior in some minor way.
> While that might be a little larger than the code required to call printf,
> such substitutions will generally allow the printf function to be eliminated
> entirely. Of course, such substitutions are only legitimate if they would
> produce the same output as printf.
>
> The above approach doesn't work superbly well in cases with the normal
> compile-link approach, but an embedded compiler which takes all the C files
> and produces an executable can observe which aspects of printf are actually
> used and include just those in the output file. Another variation is to
> have each compiler generate a weakly-linked version of "printf" which will
> satisfy its needs, and prioritize them such that the most advanced version
> of printf that is required will get built into an executable. That only
> works if printf features are ranked, but can still offer some pretty big
> advantages if most programs use the cheaper versions. As noted, though,
> the substitution requires that the compiler achieve consistent behaviors
> among all forms of printf that it uses.
A similar thing I've heard about is a C implementation that would use a
version of printf that doesn't support floating-point by default,
switching to a fully functioning version if you used the "-lm" option or
equivalent. Which meant that a program that used floating-point but not
the math library could fail. The workaround was to add "-lm" when
linking. I don't remember which implemention this was.
--
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 | wssimms@gmail.com |
|---|---|
| Date | 2015-09-18 19:47 -0700 |
| Message-ID | <b0156d6e-bd89-474c-9210-da710c7b65bc@googlegroups.com> |
| In reply to | #70904 |
Am Samstag, 19. September 2015 03:15:01 UTC+9 schrieb Keith Thompson:
> A similar thing I've heard about is a C implementation that would use a
> version of printf that doesn't support floating-point by default,
> switching to a fully functioning version if you used the "-lm" option or
> equivalent. Which meant that a program that used floating-point but not
> the math library could fail. The workaround was to add "-lm" when
> linking. I don't remember which implemention this was.
You may be thinking of Dennis Ritchie's PDP-11 C compiler. Here is the
relevant code from pass 2:
/*
* If any floating-point instructions
* were used, generate a reference which
* pulls in the floating-point part of printf.
*/
if (nfloat)
printf(".globl fltused\n");
However, this doesn't require -lm, but rather depends on the use of
float or double values in the source code.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2015-09-18 19:56 -0700 |
| Message-ID | <c65b1de6-c3ea-47c0-8523-0b372b0bc03b@googlegroups.com> |
| In reply to | #70913 |
Am Samstag, 19. September 2015 11:47:47 UTC+9 schrieb wss...@gmail.com:
> Am Samstag, 19. September 2015 03:15:01 UTC+9 schrieb Keith Thompson:
> > A similar thing I've heard about is a C implementation that would use a
> > version of printf that doesn't support floating-point by default,
> > switching to a fully functioning version if you used the "-lm" option or
> > equivalent. Which meant that a program that used floating-point but not
> > the math library could fail. The workaround was to add "-lm" when
> > linking. I don't remember which implemention this was.
>
> You may be thinking of Dennis Ritchie's PDP-11 C compiler. Here is the
> relevant code from pass 2:
>
> /*
> * If any floating-point instructions
> * were used, generate a reference which
> * pulls in the floating-point part of printf.
> */
> if (nfloat)
> printf(".globl fltused\n");
>
> However, this doesn't require -lm, but rather depends on the use of
> float or double values in the source code.
Sorry. replying to myself to point out that the destination of this
printf() is the final output file, not stdout. I copied the code from
the 6th edition Unix source. In that system, the i/o library functions
all operated on two global file descriptor variables named 'fin'
and 'fout'.
To redirect output, you simply assigned a new file descriptor to
the variable (possibly saving the old value for later restoration).
It sounds kind of primitive, but before that the method was to
simply close file descriptor 1 and then open the file you wanted
for writing, which would be assigned file descriptor 1, as it is
now guaranteed to be the lowest unused descriptor.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-19 03:57 +0000 |
| Message-ID | <mtimfd$il$1@speranza.aioe.org> |
| In reply to | #70913 |
wssimms@gmail.com wrote:
> Am Samstag, 19. September 2015 03:15:01 UTC+9 schrieb Keith Thompson:
>> A similar thing I've heard about is a C implementation that would use a
>> version of printf that doesn't support floating-point by default,
>> switching to a fully functioning version if you used the "-lm" option or
>> equivalent. Which meant that a program that used floating-point but not
>> the math library could fail. The workaround was to add "-lm" when
>> linking. I don't remember which implemention this was.
> You may be thinking of Dennis Ritchie's PDP-11 C compiler. Here is the
> relevant code from pass 2:
> /*
> * If any floating-point instructions
> * were used, generate a reference which
> * pulls in the floating-point part of printf.
> */
> if (nfloat)
> printf(".globl fltused\n");
> However, this doesn't require -lm, but rather depends on the use of
> float or double values in the source code.
I think I remember some compilers for MSDOS that also did this.
The problem came if you did something like:
printf("%e",*((double*)p));
where p might not be a pointer to double.
Though it seems that you could:
double d;
scanf("%le",&d);
printf("%e",d);
with no generated floating point instructions, but legal C.
In the early MSDOS days, and likely also in the PDP-11 days,
floating point was usually done in software. In addition to the
conversion routines, all the floating point emulation routines
could be optionally loaded.
-- glen
-- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-09-23 12:32 +0000 |
| Message-ID | <56029b9c.15355078@news.xs4all.nl> |
| In reply to | #70845 |
supercat@casperkitty.com wrote: > On Thursday, September 17, 2015 at 1:52:59 PM UTC-5, Keith Thompson wrote: > > A C implementation is made up of components that have to work correctly > > together. The standard has nothing to say about how those components > > are coordinated or distributed, only that the final product has to work > > in certain ways. The way it's done on each system depends on what > > happens to be most convenient for that system, or on the whim of the > > implementers. > > I would suggest that a product that calls itself a "C11 implementation for > AcmeOS 3.4" should enable anyone who has AcmeOS 3.4 and everything required > to use it, along with source code for a strictly-conforming program, to be > able to run that program. You are, of course, entirely correct. Which is why the GNU Foundation(tm) is very careful _never_ to take that responsibility. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-16 18:28 -0500 |
| Message-ID | <kgujvad8msugmhefio3daha25kbc73hrr7@4ax.com> |
| In reply to | #70743 |
On Wed, 16 Sep 2015 15:40:27 -0700 (PDT), supercat@casperkitty.com
wrote:
>On Wednesday, September 16, 2015 at 3:35:32 PM UTC-5, Ian Collins wrote:
>> That would make just about every hosted implementation non-compliant. I
>> have several compilers on my systems and only one set of libraries
>> (those supplied by the system).
>
>Perhaps on Unix. On MS-DOS, CP/M, Windows, and Classic Macintosh the normal
>practice for hosted compilers was to include libraries which would suffice to
>generate a complete application that would use some OS-dependent method to
>perform OS operations. If user code write:
>
> FILE *f = fopen("hey","w");
> fprintf(f, "%d", 1234);
> fclose(f);
>
>then user code would invoke compiler-vendor-supplied functions for fopen,
>fprintf, and fclose. Those methods would in turn use system calls to
>open a file, feed data to it, and close it.
>
>I see no reason for the compiler vendor not to supply libraries with all the
>indicated methods. If the C Standard defines a new printf formatting option,
>and code using that option is compiled with a compiler that is supposed to
>abide by the new standard, how can compliant behavior be achieved if the
>compiler does not include a version of "printf" which supports that function?
>
>> If a compiler uses non-standard libraries, it's pretty obvious it would
>> have to include them. The same applies to a compiler for an embedded
>> target.
>
>Why should a compiler be expected to bundle a floating-point divide routine
>but not, e.g., memcpy? What advantage is there to separating out parts of
>the library from the compiler? It seems to me that such behavior creates
>needless compatibility risks, and I see no upside besides the ability to
>reduce slightly the amount of code that needs to be bundled with the compiler
>(the volume of code would be trivial by the standards of almost any modern
>development system, so that's not much of an upside).
The different parts have different dependencies and requirements. Much
of the standard library will be dependent on the OS, while most of
what the compiler does is dependent on the ISA. The linker is heavily
dependent on both, plus the needs of other languages for the platform.
Obviously all three need to work together well, so some amount of
coordination is beneficial, but they really do have disparate
concerns.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-16 16:32 -0700 |
| Message-ID | <lnh9mugctc.fsf@kst-u.example.com> |
| In reply to | #70743 |
supercat@casperkitty.com writes:
[...]
> I see no reason for the compiler vendor not to supply libraries with all the
> indicated methods. If the C Standard defines a new printf formatting option,
> and code using that option is compiled with a compiler that is supposed to
> abide by the new standard, how can compliant behavior be achieved if the
> compiler does not include a version of "printf" which supports that function?
The new printf is supplied by the provider of the standard library
implementation.
For example, on my Linux system, the compiler is provided by the "gcc"
package and (most of) the standard library is provided by the "libc6"
package.
The compiler, on seeing a call to printf, generates a function call. It
doesn't have to know how printf is implemented. That call is resolved
at link time to whatever library implementation is installed.
I have clang installed on the same system, using the same runtime
library. The developers of clang didn't have to implement the entire
runtime library, just the compiler.
On Solaris, I can compile with gcc and use Sun's (or rather Oracle's)
runtime library that was included with the operating system. I could
probably install clang there as well if I were so inclined.
It works.
Of course other schemes can also work.
[...]
--
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-09-16 11:03 -0700 |
| Message-ID | <ca64aefc-8613-4bea-b3c5-035648e4236b@googlegroups.com> |
| In reply to | #70645 |
W dniu środa, 16 września 2015 18:26:37 UTC+2 użytkownik Bart napisał: > On 16/09/2015 13:46, David Brown wrote: > > On 16/09/15 14:12, Bartc wrote: > > >> And I'm still not convinced gcc (by which I mean the whole bundle that I > >> use to turn .c sources into executables) is not at fault: > > > > My coffee cup plays an integral part in turning C sources into > > executables - but I don't consider it part of gcc. > > > Please stop this "gcc is the entire toolchain, library, include files, > > make, utilities, msys, mingw, assembler, linker" nonsense. > > Yes, and replace it with another nonsense that now, a compiler is just a > compiler, literally nothing else. > > Anyone who used to buy a C compiler off the shelf, installed the disk > then found it couldn't even compile the examples in their textbook, > would be pretty annoyed, if they had to go back to the shop and buy > something else - the standard headers. Followed a third trip to the shop > to buy the linker, and possibly followed by a fourth trip to get the > runtime library! > > Which is pretty much what happened to me yesterday: downloading gcc/tdm > 5.1, I download core system zip rather than use the installer. Then I > need to download the mingw-w64 runtime libraries in order to compiler > anything. *Then* the 'bintools' suite to link it! > > At least on the TDM site things are laid out clearly, you have the > choice of not using the installer, and it offers zip files. > > Sorry, but to me, a 'C compiler for Windows' implies the whole > package**. I'm not interested in how the different bits are structured. > (And anyone who uses "gcc program.c" to get an executable might not even > be aware there is a discrete linker. Certainly I wasn't until last week! > Why should I?) > > (**Namely, the compiler, standard C headers that provide the features > mentioned in the C standard, the linker, and the C runtime, unless > provided by the OS, but how exactly it's provided is of not much > interest provided it's available and not something that is my > responsibility to source. > > And for Windows, I would expect a windows.h file to be included plus the > means to link into the Windows APIs. Most compilers I've tried do > actually provide all. For Windows, these elements are not optional.) > this shows that compiler has two meanings like 'compiler suite' and 'thin compiler part' - both are used
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-17 08:42 +1200 |
| Message-ID | <d5u2hmFbqqoU3@mid.individual.net> |
| In reply to | #70645 |
Bartc wrote: > On 16/09/2015 13:46, David Brown wrote: >> On 16/09/15 14:12, Bartc wrote: > >>> And I'm still not convinced gcc (by which I mean the whole bundle that I >>> use to turn .c sources into executables) is not at fault: >> >> My coffee cup plays an integral part in turning C sources into >> executables - but I don't consider it part of gcc. > >> Please stop this "gcc is the entire toolchain, library, include files, >> make, utilities, msys, mingw, assembler, linker" nonsense. > > Yes, and replace it with another nonsense that now, a compiler is just a > compiler, literally nothing else. Which on most platforms it almost is. I qualified the last sentence because the compiler "bundle" will usually include the application or script to drive the compilation process. We've already discussed why the standard libraries (especially the C run time) is more tightly coupled to the host system than it is to the compiler. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-16 22:53 +0200 |
| Message-ID | <mtckp0$6ga$1@dont-email.me> |
| In reply to | #70645 |
On 16/09/15 18:26, Bartc wrote: > On 16/09/2015 13:46, David Brown wrote: >> On 16/09/15 14:12, Bartc wrote: > >>> And I'm still not convinced gcc (by which I mean the whole bundle that I >>> use to turn .c sources into executables) is not at fault: >> >> My coffee cup plays an integral part in turning C sources into >> executables - but I don't consider it part of gcc. > >> Please stop this "gcc is the entire toolchain, library, include files, >> make, utilities, msys, mingw, assembler, linker" nonsense. > > Yes, and replace it with another nonsense that now, a compiler is just a > compiler, literally nothing else. Yes, a compiler is a compiler - and almost nothing else. Standard headers, as defined by the C standards (not the target OS), may be included where the main C library is not involved (thus gcc has <stdint.h>, but not <stdio.h>, as that is part of the library). And there will be some basic libraries covering the C startup code, floating point support functions, and any emulation needed for C that is not provided by the hardware. > > Anyone who used to buy a C compiler off the shelf, installed the disk > then found it couldn't even compile the examples in their textbook, > would be pretty annoyed, if they had to go back to the shop and buy > something else - the standard headers. Followed a third trip to the shop > to buy the linker, and possibly followed by a fourth trip to get the > runtime library! What they would be buying is a C compiler /toolchain/. A /toolchain/ is a chain of tools - all the bits you need to compile, assemble, and link your code. The compiler is part of that. The first C compiler I used professionally came on a separate disk, as a separately purchased item, from the disk containing the assembler and linker. > > Which is pretty much what happened to me yesterday: downloading gcc/tdm > 5.1, I download core system zip rather than use the installer. Then I > need to download the mingw-w64 runtime libraries in order to compiler > anything. *Then* the 'bintools' suite to link it! You knowingly downloaded a bit of the toolchain, and then complain that you only have a bit of the toolchain. > > At least on the TDM site things are laid out clearly, you have the > choice of not using the installer, and it offers zip files. > > Sorry, but to me, a 'C compiler for Windows' implies the whole > package**. I'm not interested in how the different bits are structured. > (And anyone who uses "gcc program.c" to get an executable might not even > be aware there is a discrete linker. Certainly I wasn't until last week! > Why should I?) If you are interested in why something is not working the way you think it should work, and are so keen to blame "gcc" even before you know the problem, then you /should/ be interested in how your toolchain is structured. How would you ever expect to get help or support from the right developers? Of course, it seems like you are more interested in moaning to innocent bystanders than actually trying to find out about your problems. > > (**Namely, the compiler, standard C headers that provide the features > mentioned in the C standard, the linker, and the C runtime, unless > provided by the OS, but how exactly it's provided is of not much > interest provided it's available and not something that is my > responsibility to source. > > And for Windows, I would expect a windows.h file to be included plus the > means to link into the Windows APIs. Most compilers I've tried do > actually provide all. For Windows, these elements are not optional.) >
[toc] | [prev] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2015-09-16 22:23 +0000 |
| Message-ID | <d5u8enF8k4U2@mid.uni-berlin.de> |
| In reply to | #70708 |
David Brown <david.brown@hesbynett.no> wrote:
> On 16/09/15 18:26, Bartc wrote:
> > Anyone who used to buy a C compiler off the shelf, installed the disk
> > then found it couldn't even compile the examples in their textbook,
> > would be pretty annoyed, if they had to go back to the shop and buy
> > something else - the standard headers. Followed a third trip to the shop
> > to buy the linker, and possibly followed by a fourth trip to get the
> > runtime library!
> What they would be buying is a C compiler /toolchain/. A /toolchain/ is
> a chain of tools - all the bits you need to compile, assemble, and link
> your code. The compiler is part of that.
I guess he'll also complain when he gets a professional class
power drill as a gift that there are no drill bits coming with
it, next that there are no screws, and then that the screw
anchors are missing. It has to be obvious to everyone that he
is entitled to receive the full packages of everything he may
ever think of doing with the power drill! And reading what's
written in the description on the outside is too complex and
confusing. He should gang up with "fir", they'd make a per-
fect pair.
> If you are interested in why something is not working the way you think
> it should work, and are so keen to blame "gcc" even before you know the
> problem, then you /should/ be interested in how your toolchain is
> structured. How would you ever expect to get help or support from the
> right developers?
Please, please stop trying to implant the idea of asking the
developers into his head! Think of the poor guys that would
have to deal with his constant whining. That would be cruel
and unusual punishment...
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-09-16 15:34 -0700 |
| Message-ID | <be53772b-c5f7-4b33-a592-af50766d792f@googlegroups.com> |
| In reply to | #70739 |
W dniu czwartek, 17 września 2015 00:23:29 UTC+2 użytkownik Jens Thoms Toerring napisał: > David Brown <david.brown@hesbynett.no> wrote: > > On 16/09/15 18:26, Bartc wrote: > > > Anyone who used to buy a C compiler off the shelf, installed the disk > > > then found it couldn't even compile the examples in their textbook, > > > would be pretty annoyed, if they had to go back to the shop and buy > > > something else - the standard headers. Followed a third trip to the shop > > > to buy the linker, and possibly followed by a fourth trip to get the > > > runtime library! > > > What they would be buying is a C compiler /toolchain/. A /toolchain/ is > > a chain of tools - all the bits you need to compile, assemble, and link > > your code. The compiler is part of that. > > I guess he'll also complain when he gets a professional class > power drill as a gift that there are no drill bits coming with > it, next that there are no screws, and then that the screw > anchors are missing. It has to be obvious to everyone that he > is entitled to receive the full packages of everything he may > ever think of doing with the power drill! And reading what's > written in the description on the outside is too complex and > confusing. He should gang up with "fir", they'd make a per- > fect pair. > ye i also dislike dependencies (on libraries, layers, tools) (the rest of this thread i dont read to much, so i cannot commant to much) > > If you are interested in why something is not working the way you think > > it should work, and are so keen to blame "gcc" even before you know the > > problem, then you /should/ be interested in how your toolchain is > > structured. How would you ever expect to get help or support from the > > right developers? > > Please, please stop trying to implant the idea of asking the > developers into his head! Think of the poor guys that would > have to deal with his constant whining. That would be cruel > and unusual punishment... > Regards, Jens > -- > \ Jens Thoms Toerring ___ jt@toerring.de > \__________________________ http://toerring.de
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-16 16:07 -0700 |
| Message-ID | <ee23895b-55c2-4a6a-898f-41fcd327fc0f@googlegroups.com> |
| In reply to | #70739 |
On Wednesday, September 16, 2015 at 5:23:29 PM UTC-5, Jens Thoms Toerring wrote: > I guess he'll also complain when he gets a professional class > power drill as a gift that there are no drill bits coming with > it, next that there are no screws, and then that the screw > anchors are missing. It has to be obvious to everyone that he > is entitled to receive the full packages of everything he may > ever think of doing with the power drill! And reading what's > written in the description on the outside is too complex and > confusing. He should gang up with "fir", they'd make a per- > fect pair. I'd be annoyed if I bought a US household wall-powered drill which claims to work with standard bits, along with some standard bits to go with it, and then discovered after getting home that the drill couldn't actually use it with standard bits unless I also bought a chuck which was not included with the drill and also had three-phase power (not common in US households). While it might be possible to buy equipment that would make it possible to use the drill with household power and standard bits, the drill as sold would not conform to the standards for a US household-powered appliance nor a drill that accepted standard bits. A C compiler package for e.g. Classic Mac OS should enable who has the necessary OS files to run the compiler to in turn use that compiler to run programs under that same OS. A compiler written in 68000 machine code that generated 68000 machine code but needed additional library files to work with the Macintosh OS should bill itself as a non-hosted 68000 compiler if it contains sufficient libraries for that (and I see no reason a compiler shouldn't). The C Standard doesn't say that implementations should come with every imaginable library under the sun, but does specify a minimal set of functions that C implementations are required to supply. Something that does not include those functions is not a standard-compliant C implementation.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-17 11:20 +1200 |
| Message-ID | <d5ubqnFbqqoU6@mid.individual.net> |
| In reply to | #70744 |
supercat@casperkitty.com wrote: > > The C Standard doesn't say that implementations should come with every > imaginable library under the sun, but does specify a minimal set of functions > that C implementations are required to supply. So do platform standards which extend the C standard such as POSIX. > Something that does not > include those functions is not a standard-compliant C implementation. Windows? Is this the key philosophical difference: POSIX embraces the C standard while Windows tries to ignore it? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-16 16:44 -0700 |
| Message-ID | <88472ee4-e3bf-4d69-8f36-188c1b46f229@googlegroups.com> |
| In reply to | #70750 |
On Wednesday, September 16, 2015 at 6:21:05 PM UTC-5, Ian Collins wrote: > Is this the key philosophical difference: POSIX embraces the C standard > while Windows tries to ignore it? One could take the alternative view that Windows is designed to be language agnostic, while Unix is designed to tie its behavior and version to the C language, such that it will not be possible to use the same version of the OS to run a programs which were developed for use with compilers that had slightly different, but legal, "printf" semantics. I tend to take the view that applications should generally supply their own code for things whose intended semantics are better known by the application than by the OS, and where it might make sense for different applications to use different semantics. If one application needs a "sin" function which produces results which are accurate to within 32769/65536ULP, while another would rather have a "sin" function that produces results more quickly to within 3/4ULP, what is gained by having both programs call a system library "sin" function, which would have to favor one or the other?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 13:18 +0000 |
| Message-ID | <560e83e3.15588093@news.xs4all.nl> |
| In reply to | #70759 |
supercat@casperkitty.com wrote: > On Wednesday, September 16, 2015 at 6:21:05 PM UTC-5, Ian Collins wrote: > > Is this the key philosophical difference: POSIX embraces the C standard > > while Windows tries to ignore it? > > One could take the alternative view that Windows is designed to be language > agnostic, while Unix is designed to tie its behavior and version to the C > language, such that it will not be possible to use the same version of the > OS to run a programs which were developed for use with compilers that had > slightly different, but legal, "printf" semantics. That wouldn't be (and wasn't) such a problem. The problem starts when it becomes tied to _one specific implementation_ of C. Oh, sorry: at least three specific, closely tied but not mutually responsible, _part-implementations_ of C. Richard
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web