Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #70345 > unrolled thread
| Started by | David Brown <david.brown@hesbynett.no> |
|---|---|
| First post | 2015-09-12 15:28 +0200 |
| Last post | 2015-09-14 10:43 +0200 |
| Articles | 20 on this page of 160 — 23 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-16 13:11 -0700 |
| Message-ID | <lnio7ai0ov.fsf@kst-u.example.com> |
| In reply to | #70684 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>
>> Yes, because that's exactly what that bundle is. Only the compiler
>> itself is properly called "gcc". Why is that concept such a problem for
>> you?
>
> As I understand it, gcc is now "GNU compiler collection" and so is
> more than one compiler,
Right.
> but yes only the compilers, but the libraries
> and the rest of the stuff.
Did you omit a "not"?
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-09-16 21:59 +0000 |
| Message-ID | <mtcoo4$nkc$3@speranza.aioe.org> |
| In reply to | #70694 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >> but yes only the compilers, but the libraries >> and the rest of the stuff. > Did you omit a "not"? I thought it, I don't know how it didn't get there. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-09-17 01:12 -0500 |
| Message-ID | <mtdlhm$51d$1@dont-email.me> |
| In reply to | #70732 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:mtcoo4$nkc$3@speranza.aioe.org... > Keith Thompson <kst-u@mib.org> wrote: > > (snip, I wrote) > >>> but yes only the compilers, but the libraries >>> and the rest of the stuff. > >> Did you omit a "not"? > > I thought it, I don't know how it didn't get there. > ! only -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-16 21:11 +0100 |
| Message-ID | <mtciak$s8u$1@dont-email.me> |
| In reply to | #70681 |
On 16/09/2015 20:28, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> David Brown objected to that because he (and apparently everyone else >> here) likes to think of that bundle as lots of different subsystems, all >> with their own identify, written by different people and collected from >> different sources. > > Yes, because that's exactly what that bundle is. Only the compiler > itself is properly called "gcc". Why is that concept such a problem for > you? Well in this case, it means if I have a problem with the 'bundle incorrectly referred to as gcc', then I don't know what to put the blame on! (Which sounds a bit of a cop-out.) Take the problem I had further up the thread, and suppose it hadn't been solved (the solution was more a workaround IMO). What advice could I give about a suitable C compiler to someone who wanted to compile my code? 'Yes, you can use gcc, but only the bare compiler; you will have to source a different set of headers and libraries from somewhere else'? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-16 13:53 -0700 |
| Message-ID | <ln613ahys3.fsf@kst-u.example.com> |
| In reply to | #70695 |
Bartc <bc@freeuk.com> writes:
> On 16/09/2015 20:28, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> David Brown objected to that because he (and apparently everyone else
>>> here) likes to think of that bundle as lots of different subsystems, all
>>> with their own identify, written by different people and collected from
>>> different sources.
>>
>> Yes, because that's exactly what that bundle is. Only the compiler
>> itself is properly called "gcc". Why is that concept such a problem for
>> you?
>
> Well in this case, it means if I have a problem with the 'bundle
> incorrectly referred to as gcc', then I don't know what to put the blame
> on! (Which sounds a bit of a cop-out.)
Who is referring to the bundle as "gcc"? What bundle are you
talking about?
If you're using an implementation that was distributed *as a full
implementation*, presumably any problems should be reported to the
distributor.
> Take the problem I had further up the thread, and suppose it hadn't been
> solved (the solution was more a workaround IMO). What advice could I
> give about a suitable C compiler to someone who wanted to compile my code?
>
> 'Yes, you can use gcc, but only the bare compiler; you will have to
> source a different set of headers and libraries from somewhere else'?
The advice I'd give is "You need a C implementation".
There are a number of C implementations that include gcc, so it
shouldn't normally be necessary to assemble your own from components.
You can if you like, but you have to know what you're doing;
I wouldn't try it myself.
MinGW is a common choice for Windows; I'm sure there are others.
(When I used Windows I always installed Cygwin, but I understand
you don't want to impose that as a requirement on your users.)
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-16 23:07 +0200 |
| Message-ID | <mtcljd$9sk$1@dont-email.me> |
| In reply to | #70695 |
On 16/09/15 22:11, Bartc wrote: > On 16/09/2015 20:28, Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: > >>> David Brown objected to that because he (and apparently everyone else >>> here) likes to think of that bundle as lots of different subsystems, all >>> with their own identify, written by different people and collected from >>> different sources. >> >> Yes, because that's exactly what that bundle is. Only the compiler >> itself is properly called "gcc". Why is that concept such a problem for >> you? > > Well in this case, it means if I have a problem with the 'bundle > incorrectly referred to as gcc', then I don't know what to put the blame > on! (Which sounds a bit of a cop-out.) All the more reason for you to learn what you are actually using! You got the bundle from TDM - why is it so hard to understand that TDM are responsible for the bundle? If you have a problem that the wheels keep locking on your car, would you deal with it by going to alt.cars and moaning about problems with your Goodyear? After all, it says Goodyear on the tires - they /must/ be the people responsible for everything in the car. > > Take the problem I had further up the thread, and suppose it hadn't been > solved (the solution was more a workaround IMO). It was a ******* good solution I gave you, not a workaround. Despite your continuous efforts to blame everyone, and especially gcc, for your inability to understand the solution or read the gcc manual, it /is/ the right way to handle it - and I cannot comprehend why you don't want to implement it. All I can say here is I'm glad no one else has to deal with your tools when that's your attitude to fixing problems. > What advice could I > give about a suitable C compiler to someone who wanted to compile my code? > > 'Yes, you can use gcc, but only the bare compiler; you will have to > source a different set of headers and libraries from somewhere else'? >
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-16 23:10 +0100 |
| Message-ID | <mtcp95$rko$1@dont-email.me> |
| In reply to | #70714 |
On 16/09/2015 22:07, David Brown wrote: > On 16/09/15 22:11, Bartc wrote: >> Take the problem I had further up the thread, and suppose it hadn't been >> solved (the solution was more a workaround IMO). > > It was a ******* good solution I gave you, not a workaround. Despite > your continuous efforts to blame everyone, and especially gcc, ... > it /is/ the > right way to handle it - and I cannot comprehend why you don't want < > to implement it. The fix was appreciated and it has been implemented. (As a couple of lines in my compiler that creates the C. Remember I'm one step removed from writing actual C code directly.) So that's it as far as I'm concerned (half of my code that generates C is workarounds to bypass various problems anyway!). But forget what I'm doing: it's a little unsatisfactory because someone else compiling a MainWndProc callback function with -O3, that might contain these aligned 128-bit ops, might have the same problem. A better fix is for the CALLBACK macro to contain that attribute as you suggested. Then it's fixed in one place instead of in a thousand applications which still requires the authors, if available, to rediscover the bug and the fix. Maybe I /will/ file a bug report if I can find out where and how. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-17 10:26 +0200 |
| Message-ID | <mtdtcb$th0$2@dont-email.me> |
| In reply to | #70736 |
On 17/09/15 00:10, Bartc wrote: > On 16/09/2015 22:07, David Brown wrote: >> On 16/09/15 22:11, Bartc wrote: > >>> Take the problem I had further up the thread, and suppose it hadn't been >>> solved (the solution was more a workaround IMO). >> >> It was a ******* good solution I gave you, not a workaround. Despite >> your continuous efforts to blame everyone, and especially gcc, > ... >> it /is/ the >> right way to handle it - and I cannot comprehend why you don't want < >> to implement it. > > The fix was appreciated and it has been implemented. (As a couple of > lines in my compiler that creates the C. Remember I'm one step removed > from writing actual C code directly.) > > So that's it as far as I'm concerned (half of my code that generates C > is workarounds to bypass various problems anyway!). > > But forget what I'm doing: it's a little unsatisfactory because someone > else compiling a MainWndProc callback function with -O3, that might > contain these aligned 128-bit ops, might have the same problem. > > A better fix is for the CALLBACK macro to contain that attribute as you > suggested. Then it's fixed in one place instead of in a thousand > applications which still requires the authors, if available, to > rediscover the bug and the fix. Maybe I /will/ file a bug report if I > can find out where and how. > That I agree on. But you have to find out where the windows.h file comes from, and file the bug with the right people - not gcc.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-16 22:59 +0200 |
| Message-ID | <mtcl3b$7ms$1@dont-email.me> |
| In reply to | #70677 |
On 16/09/15 20:53, Bartc wrote: > On 16/09/2015 18:48, Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: >>> 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. > >> If you want to complain that something you've downloaded is only >> a compiler and not a working C implementation, that's a different >> matter. But of course you've already made that point multiple times, >> and complained about it to people who are not in a position to do >> anything about it. > > This sub-thread came about from my casual use of "gcc" to mean the > entire bundle of executables, dynamic libraries, library files, include > files etc etc that all co-exist under a single directory on my machine, > and of which the overall purpose, the raison d'etre, is to put in C > source files at one end and come out with object, executable or dynamic > libraries at the other. > > David Brown objected to that because he (and apparently everyone else > here) likes to think of that bundle as lots of different subsystems, all > with their own identify, written by different people and collected from > different sources. > > That may be accurate, but how many really care? And can't it be said > also of any bundled compiler suite? For all I know, DMC consists of a > dozen components assembled from different places, but if I have a > problem with it, then to me it's a problem with DMC; the problem is with > the bundle. There is no "may be" about it - it /is/ accurate. You should not be so proud of your ignorance. Now, if you had been talking about the TDM toolchain, instead of the gcc compiler, things would have been very different. It is the TDM toolchain that is the equivalent of packages you get from DMC, MSVC or LLCWIN. It is not unlikely that DMC have taken bits from different places, such as getting the library from one place, the assembler from another, and writing their own compiler - and then they have bundled it together and accept a certain responsibility for the complete package. TDM does the same, as does for example Debian Linux when they make the build-essentials package. gcc is one part of that toolchain - it is the compiler. Is this so hard to understand? > > These are the C compilers known to my IDE: > > 1 : GCC <32> 32-bit [No longer installed] > 2 : Pelles C <64> 32/64-bit > 3 : Lccwin <64> 32/64-bit > 4 : DMC <32> 32-bit > 5 : GCC TDM <64> 32/64-bit > 6 : TCC <64> 32/64-bit > 7 : GCC99 <32> 32-bit > 8 : G++ <64> 32/64-bit > > Notice the whole GCC/TDM compiler suite or bundle, is just called > GCC/TDM. If compiler #5 has a problem, I'll switch to #6. Why? Because > GCC/TDM is not working; it doesn't matter than the actual problem is in > some tiny part of the 400MB installation that is not gcc.exe. > > While the choice of linker is this: > > 1 : Use C linker > 2 : Use LD linker > > #1 means the bundled linker of whichever C compiler is chosen. They > don't like getting mixed up! (#2 is used when I'm linking an ASM project.) >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-16 13:15 -0700 |
| Message-ID | <f668cb38-1f1a-4f97-87d4-04fbf4cbe0c4@googlegroups.com> |
| In reply to | #70663 |
On Wednesday, September 16, 2015 at 12:48:33 PM UTC-5, Keith Thompson wrote: > If you want to complain that something you've downloaded is only > a compiler and not a working C implementation, that's a different > matter. But of course you've already made that point multiple times, > and complained about it to people who are not in a position to do > anything about it. Note that the C Standard does not recognize any such thing as a "compiler" in the sense you describe, and thus it is meaningless to describe a compiler by itself as complying with any version of the C Standard. For a C implementation to comply with the C Standard, it must contain everything necessary to make a computer perform the actions indicated by a strictly-conforming program. The notion that a compiler should be packaged separately from the libraries that are required for use with it is an odd one that is not supported by the C Standard. If a C compiler needs to use any library functions in any contexts other than a function call (a common situation on machines without floating-point units) the Standard would provide no guidance about what any such functions might be, but a compiler is unlikely to behave in accordance with the C Standard unless bundled with a library that provides functions with the same semantics as the compiler is expecting.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-17 08:35 +1200 |
| Message-ID | <d5u249FbqqoU2@mid.individual.net> |
| In reply to | #70696 |
supercat@casperkitty.com wrote: > > The notion that a compiler should be packaged separately from the libraries > that are required for use with it is an odd one that is not supported by the > C Standard. 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). > If a C compiler needs to use any library functions in any > contexts other than a function call (a common situation on machines without > floating-point units) the Standard would provide no guidance about what any > such functions might be, but a compiler is unlikely to behave in accordance > with the C Standard unless bundled with a library that provides functions > with the same semantics as the compiler is expecting. 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. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-16 15:40 -0700 |
| Message-ID | <f82459bf-2e32-4863-9edb-6ef54959d17f@googlegroups.com> |
| In reply to | #70703 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-17 11:16 +1200 |
| Message-ID | <d5ubj7FbqqoU5@mid.individual.net> |
| In reply to | #70743 |
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.
There's nothing to stop them, but to do so they would have to provide
libraries for all their supported platforms and unless the platform has
strong ABI guarantees, all supported versions of those platforms.
That's a lot of work that someone else will have already done.
> 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?
It can't which is why we have platform standards such as POSIX which are
based upon the C standard. This is why programmer unfriendly platforms
are a pain for compiler vendors wanting to support modern C. I assume
the likes of Jacob have to supply their own standard libraries.
As a side note, Windows C programmers should be grateful to the C++
committee for including more of C99 in the C++11 standard!
>> 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?
Because there already is memcpy in the platform libraries. At least in
the Unix domain nearly all of the command line utilities are C
applications, so the standard libraries have to be present for them to
run. Those at aren't use interpreters that are C or C++ applications,
thus all of the command line utilities and user space system libraries
use the standard libraries.
> What advantage is there to separating out parts of the library from the compiler?
Why force every compiler to rewrite what is already there? Should every
tool that reads XML include it's own parser?
> 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).
I guess one analogy is C its self. We could force all software to be
written in naive assembler, but we use C as an abstract machine. In the
same way we could force every tool to use the native system call
interface, but we use the C standard library.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-17 10:38 +0200 |
| Message-ID | <mtdu2m$hj$1@dont-email.me> |
| In reply to | #70748 |
On 17/09/15 01:16, Ian Collins wrote:
> 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.
>
> There's nothing to stop them, but to do so they would have to provide
> libraries for all their supported platforms and unless the platform has
> strong ABI guarantees, all supported versions of those platforms. That's
> a lot of work that someone else will have already done.
>
There is also the fact that the system calls that actually do the work
in a function like fopen() are dependent on the OS - so it makes most
sense for the library that implements fopen() to be an OS library, not a
compiler library.
>> 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?
>
> It can't which is why we have platform standards such as POSIX which are
> based upon the C standard. This is why programmer unfriendly platforms
> are a pain for compiler vendors wanting to support modern C. I assume
> the likes of Jacob have to supply their own standard libraries.
>
> As a side note, Windows C programmers should be grateful to the C++
> committee for including more of C99 in the C++11 standard!
>
>>> 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?
The C standards define floating point divide to be part of the language
itself, not part of the library. So the compiler must generate code
that does floating point division, including any necessary library code.
memcpy, on the other hand, is defined as part of the C library - and can
thus be part of the external library. And in theory, the external C
library could use additional OS or hardware features that the compiler
library could not, such as using DMA for large memcpy calls.
Having said that, there is nothing to stop a compiler also implementing
memcpy. Compilers will often generate inline code or calls to
specialised functions when it will speed up the memcpy (for example, if
the compiler can see that the arguments are all 4-byte aligned and the
size is a multiple of 4, then the memcpy could be done using 32-bit moves).
>
> Because there already is memcpy in the platform libraries. At least in
> the Unix domain nearly all of the command line utilities are C
> applications, so the standard libraries have to be present for them to
> run. Those at aren't use interpreters that are C or C++ applications,
> thus all of the command line utilities and user space system libraries
> use the standard libraries.
>
>> What advantage is there to separating out parts of the library from
>> the compiler?
>
> Why force every compiler to rewrite what is already there? Should every
> tool that reads XML include it's own parser?
>
>> 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).
>
> I guess one analogy is C its self. We could force all software to be
> written in naive assembler, but we use C as an abstract machine. In the
> same way we could force every tool to use the native system call
> interface, but we use the C standard library.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-17 09:17 -0700 |
| Message-ID | <lnvbb9f2b2.fsf@kst-u.example.com> |
| In reply to | #70780 |
David Brown <david.brown@hesbynett.no> writes:
[...]
>> supercat@casperkitty.com wrote:
[...]
>>> Why should a compiler be expected to bundle a floating-point divide
>>> routine but not, e.g., memcpy?
>
> The C standards define floating point divide to be part of the language
> itself, not part of the library. So the compiler must generate code
> that does floating point division, including any necessary library code.
>
> memcpy, on the other hand, is defined as part of the C library - and can
> thus be part of the external library. And in theory, the external C
> library could use additional OS or hardware features that the compiler
> library could not, such as using DMA for large memcpy calls.
I think you're making a distinction that isn't particularly relevant.
If I write a floating-point multiplication, the compiler can generate
either inline machine code to perform the operation, or a function call.
If I write a call to memcpy(), the compiler can generate either inline
machine code to perform the operation, or a function call.
In both cases, if the compiler generates a function call, the function
can be resolved to a call in a library provided by the compiler
provider, by the runtime library provider, by the operating system, or
by some third party. The compiler could even emit code for the function
within the translation unit (I can imagine circumstances where that
would make sense).
Compilers can treat memcpy() specially in part because it's a standard
function, with semantics defined by the standard. A compiler can
generate any code it likes, as long as it works the way a function call
would.
> Having said that, there is nothing to stop a compiler also implementing
> memcpy. Compilers will often generate inline code or calls to
> specialised functions when it will speed up the memcpy (for example, if
> the compiler can see that the arguments are all 4-byte aligned and the
> size is a multiple of 4, then the memcpy could be done using 32-bit moves).
[...]
The choice of whether a given library function -- whether it's part of
the C standard library, or a language support function like a
floating-point division function on a system without hardware FP, or
something else -- is generally made on the basis of *convenience*.
The same is true for headers.
Of course it's perfectly valid for an entire implementation (compiler,
headers, library, linker, etc.) to be provided as part of a single
coherent project. That also is a choice made on the basis of
convenience.
--
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-17 11:08 -0700 |
| Message-ID | <190f35b2-0c49-41eb-88b7-1dca3c0e3026@googlegroups.com> |
| In reply to | #70834 |
On Thursday, September 17, 2015 at 11:17:29 AM UTC-5, Keith Thompson wrote:
> If I write a floating-point multiplication, the compiler can generate
> either inline machine code to perform the operation, or a function call.
>
> If I write a call to memcpy(), the compiler can generate either inline
> machine code to perform the operation, or a function call.
If a C program requests either operation, and a compiler generates a function
call, then a function to perform the appropriate operation must exist
somewhere. Given that the behaviors of both operations are defined by the
C Standard, is there any reason that one of those external functions should be
expected to be bundled with the compiler and the other one not?
Further, while I see no logical reason why one platform shouldn't be able to
run both C99 and C11 programs, I see no clean way of handling something like:
sscanf("11", "%hhd", &variable);
whose behavior is defined differently in C99 and C11. If the compiler itself
is responsible for supplying the sscanf function, it can ensure that the code
will behave according to the appropriate language specification, but unless
the platform includes both a "__sscanf_c99" and a "__sscanf_c11" function or
has some other means of knowing what standard to apply, I don't see how a
"scanf" built into the platform can work in both cases.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-17 11:52 -0700 |
| Message-ID | <lneghwg9on.fsf@kst-u.example.com> |
| In reply to | #70839 |
supercat@casperkitty.com writes:
> On Thursday, September 17, 2015 at 11:17:29 AM UTC-5, Keith Thompson wrote:
>> If I write a floating-point multiplication, the compiler can generate
>> either inline machine code to perform the operation, or a function call.
>>
>> If I write a call to memcpy(), the compiler can generate either inline
>> machine code to perform the operation, or a function call.
>
> If a C program requests either operation, and a compiler generates a
> function call, then a function to perform the appropriate operation
> must exist somewhere. Given that the behaviors of both operations are
> defined by the C Standard, is there any reason that one of those
> external functions should be expected to be bundled with the compiler
> and the other one not?
Yes, there could be any number of reasons, but they're going to vary
from one OS to another and from one implementation to another.
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.
Is there any reason that the C standard should specify more about this
than it already does? What exactly is the problem that you're seeing?
> Further, while I see no logical reason why one platform shouldn't be able to
> run both C99 and C11 programs, I see no clean way of handling something like:
>
> sscanf("11", "%hhd", &variable);
>
> whose behavior is defined differently in C99 and C11. If the compiler itself
> is responsible for supplying the sscanf function, it can ensure that the code
> will behave according to the appropriate language specification, but unless
> the platform includes both a "__sscanf_c99" and a "__sscanf_c11" function or
> has some other means of knowing what standard to apply, I don't see how a
> "scanf" built into the platform can work in both cases.
I see no difference in the way the behavior is defined in C99 vs. C11.
C99:
hh Specifies that a following d, i, o, u, x, X, or n conversion
specifier applies to an argument with type pointer to signed
char or unsigned char.
C11:
hh Specifies that a following d, i, o, u, x, X, or n conversion
specifier applies to an argument with type pointer to signed
char or unsigned char.
The wording for the "d" conversion specifier is also identical.
Are you thinking of C90? C90 didn't have "hh", so the behavior of the
sscanf call was undefined -- so behaving in the C99/C11 manner would be
conforming. The committee is usually careful not to change the defined
behavior of existing code.
I remember you wrote something about "%hhd" recently, but I don't
remember what it was. Can you clarify?
But if the behavior of sscanf("11", "%hhd", &variable) did change from
C99 to C11, then yes, an implementation that supports both standard
would have to do something to ensure that it behaves correctly in both
cases. It could use two different sscanf functions, or it could pass an
implicit extra argument, or it could set a global variable that sscanf
pays attention to (the latter would probably be the simplest approach).
Bundling the sscanf implementation with the compiler rather than with
the library doesn't change these considerations in any way that I can
see. Both behaviors would still have to be supported regardless of who
implements them.
(Of course as far as ISO is concerned, the C11 standard superseded and
replaced the C99 standard, so conformance to C99 is strictly irrelevant.
But in real life people do want implementations that conform to older
standards -- and in practice that's generally what we have.)
--
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-17 12:33 -0700 |
| Message-ID | <0e3b5ea5-2220-4725-b0a8-3659db4aad1a@googlegroups.com> |
| In reply to | #70843 |
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. If it requires anything which someone running
AcmeOS 3.4 might not have, then it should not be called a "C11 implementation for AcmeOS 3.4", but rather e.g. a "C11 implementation for use with BobLib 2.7
running on AcmeOS 3.4".
> Are you thinking of C90? C90 didn't have "hh", so the behavior of the
> sscanf call was undefined -- so behaving in the C99/C11 manner would be
> conforming. The committee is usually careful not to change the defined
> behavior of existing code.
There are some corner cases whose behavior of something which was legal under
an older standard has changed; I tried to formulate a simple example, but
failed in that regard. As an alternative example, how about:
printf("%20.15f", 8888.15589);
I believe implementations are allowed to output either "8888.155890000000000"
or "8888.155889999999999" (correct value is roughly 8888.15588999999999942),
and there are some cases where it might be important that the behavior be
consistent (e.g. code might check whether anything in an output file changes
from one version to another). If "printf" is supplied by the OS rather than
the C compiler, that will add a needless OS dependency on the program's
behavior.
> (Of course as far as ISO is concerned, the C11 standard superseded and
> replaced the C99 standard, so conformance to C99 is strictly irrelevant.
> But in real life people do want implementations that conform to older
> standards -- and in practice that's generally what we have.)
The only reason anyone bothers maintaining C compilers is that there's a
large amount of existing C code. Were there no need for compatibility, C
would have been replaced long ago (IMHO a cross between Turbo Pascal and
Modula-2, with a few extensions beyond either, could be a better language
than C in almost every way except the ability to run C code).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-09-17 12:55 -0700 |
| Message-ID | <040d7639-2b51-4bd4-87d6-c794cc575c87@googlegroups.com> |
| In reply to | #70845 |
On Thursday, September 17, 2015 at 8:33:52 PM UTC+1, supe...@casperkitty.com wrote: > > The only reason anyone bothers maintaining C compilers is that there's a > large amount of existing C code. Were there no need for compatibility, C > would have been replaced long ago (IMHO a cross between Turbo Pascal and > Modula-2, with a few extensions beyond either, could be a better language > than C in almost every way except the ability to run C code). > No, its because the functions that actually do difficult algorithmic work need to be in C, or it just becomes a nightmare trying to use them outside their native environment.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-17 13:20 -0700 |
| Message-ID | <ln7fnog5mw.fsf@kst-u.example.com> |
| In reply to | #70845 |
supercat@casperkitty.com writes:
> 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. If it requires anything
> which someone running AcmeOS 3.4 might not have, then it should not be
> called a "C11 implementation for AcmeOS 3.4", but rather e.g. a "C11
> implementation for use with BobLib 2.7 running on AcmeOS 3.4".
Sure, I have no particular problem with that statement. To put it
another way, any additional components required to run a C program
should be considered part of the implementation.
I'm afraid I don't see the relevance to what we were discussing.
>> Are you thinking of C90? C90 didn't have "hh", so the behavior of the
>> sscanf call was undefined -- so behaving in the C99/C11 manner would be
>> conforming. The committee is usually careful not to change the defined
>> behavior of existing code.
>
> There are some corner cases whose behavior of something which was legal under
> an older standard has changed; I tried to formulate a simple example, but
> failed in that regard. As an alternative example, how about:
>
> printf("%20.15f", 8888.15589);
>
> I believe implementations are allowed to output either "8888.155890000000000"
> or "8888.155889999999999" (correct value is roughly 8888.15588999999999942),
> and there are some cases where it might be important that the behavior be
> consistent (e.g. code might check whether anything in an output file changes
> from one version to another). If "printf" is supplied by the OS rather than
> the C compiler, that will add a needless OS dependency on the program's
> behavior.
The standard says that "the value is rounded to the appropriate number
of digits". The exact value is
8888.155889999999999 417923390865325927734375
I've inserted a space after the 15th digit after the decimal point.
My reading (which could easily be incorrect) is that either
"8888.155889999999999" or "8888.155890000000000" is permitted, and that
the choice is unspecified.
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.
Certainly the behavior can vary from one implementation to another.
Why does it matter, and more particularly why should the Standard care,
whether that variation depends on the compiler, on the runtime library,
or on the operating system?
In practice, the behavior of printf depends on the runtime library, not
on the operating system. For the system I'm using, that would be glibc
(the package name is "libc6"). Why is having the program's behavior
depend on libc6 worse than having it depend on gcc?
For a single-source implementation, where the compiler, linker, runtime
library, and so forth are developed and distributed by the same
organization, the behavior is still going to depend on the
implementation.
[...]
--
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]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web