Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98007 > unrolled thread
| Started by | Potomac <ravine557@gmail.com> |
|---|---|
| First post | 2016-12-05 06:32 -0800 |
| Last post | 2016-12-12 04:18 +0000 |
| Articles | 20 on this page of 107 — 18 participants |
Back to article view | Back to comp.lang.c
Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Potomac <ravine557@gmail.com> - 2016-12-05 06:32 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-05 08:34 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 15:43 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-05 10:41 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-05 15:37 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-05 10:43 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:13 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 10:55 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Philip Lantz <prl@canterey.us> - 2016-12-07 20:34 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 11:08 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ian Collins <ian-news@hotmail.com> - 2016-12-08 08:23 +1300
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:07 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:46 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:23 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 01:12 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:49 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-07 15:07 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 03:46 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 11:59 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 12:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-07 09:40 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:13 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 20:24 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:28 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 21:48 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:02 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 22:19 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:27 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 22:51 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:10 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 14:13 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-08 15:57 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ian Collins <ian-news@hotmail.com> - 2016-12-08 18:02 +1300
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-08 08:48 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-07 15:33 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:13 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 14:22 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-08 16:03 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:44 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Melzzzzz <Melzzzzz@zzzzz.com> - 2016-12-08 15:48 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:41 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:16 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:47 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 20:16 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops David Brown <david.brown@hesbynett.no> - 2016-12-09 11:19 +0100
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-09 08:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-13 13:55 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 01:13 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-15 07:02 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 19:56 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-18 10:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-14 11:45 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-14 12:14 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 01:24 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-15 08:02 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-15 12:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Philip Lantz <prl@canterey.us> - 2016-12-16 20:00 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:05 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:21 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-09 13:10 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:44 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops supercat@casperkitty.com - 2016-12-10 10:18 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:18 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:26 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:15 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:31 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:47 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:21 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:15 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:57 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:05 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:09 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:25 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:59 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 13:51 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 13:34 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:52 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-08 19:33 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 11:20 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops jameskuyper@verizon.net - 2016-12-09 13:28 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:51 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:46 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 13:55 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 20:17 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-07 12:23 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops twalker470@googlemail.com - 2016-12-07 05:50 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 08:55 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 16:23 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-07 10:56 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops potomac <ravine557@gmail.com> - 2016-12-07 04:14 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Barry Schwarz <schwarzb@dqel.com> - 2016-12-07 11:03 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops John Bode <jfbode1029@gmail.com> - 2016-12-09 08:06 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Keith Thompson <kst-u@mib.org> - 2016-12-09 09:23 -0800
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 17:38 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 14:01 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 19:09 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-09 12:38 -0700
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:08 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:16 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:59 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 11:51 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:22 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:52 +0000
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:32 -0500
Re: Stumped on the role of a particular statement in a program with Arrays & Nested For Loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:18 +0000
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 21:41 -0500 |
| Message-ID | <o2d5hl$oha$4@jstuckle.eternal-september.org> |
| In reply to | #98374 |
On 12/8/2016 10:48 AM, Melzzzzz wrote: > On 2016-12-08, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> >>> Yes. Since we have been using the word "compiler" it's a reasonable >>> objection. Nevertheless, if we take the linker out of the equation, *no* >>> compiler is conforming, because to leave out the linker necessarily >>> means leaving out TP8! >>> >>> And if we put the linker back into the equation, gcc fails to conform >>> even when told to by -std=c??, unless the additional magic rune -lm is >>> added, just as James explained to you already. >>> >> >> The C standard doesn't say anything about the linker (although it does >> extensively discuss linkage) or how libraries are linked in. But I >> would guess the reason for the -lm flag would be you might want to use >> libm, or you might have another library you want for the math functions. >> But I didn't write the compiler, so I don't know what they were thinking. > > gcc is used as linker frontend even for assembler programs. When libc is > needed. Lot of assembler examples assume gcc as linker front end. > So? The C standard says nothing about a front end, either. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-08 16:16 +0000 |
| Message-ID | <o2c0uf$srs$1@dont-email.me> |
| In reply to | #98372 |
On 08/12/16 15:44, Jerry Stuckle wrote: > On 12/8/2016 9:22 AM, Richard Heathfield wrote: >> On 08/12/16 14:13, Jerry Stuckle wrote: >>> On 12/7/2016 6:33 PM, jameskuyper@verizon.net wrote: >>>> On Wednesday, December 7, 2016 at 3:13:27 PM UTC-5, Jerry >>>> Stuckle wrote: >>>>> On 12/7/2016 12:40 PM, Keith Thompson wrote: >>>> ... >>>>>> Most C compilers are not conforming by default, and require >>>>>> some added options to make them (atte >>>> I >>>>>> >>>>> >>>>> Why do you say that? There is nothing that says a compiler >>>>> can't add features, as long as it does everything the >>>>> standard says it does. >>>> >>>> ... and doesn't do anything the standard says is shouldn't do. >>>> However, it turns out that most compilers do in fact fail to do >>>> something required by the standard, or do something prohibited >>>> by the standard, when invoked in their default mode. The >>>> compilers I've used most frequently over the past couple of >>>> decades all take an -ansi option that puts them in C90 mode; >>>> without that option, they don't fully conform to any version of >>>> the C standard. Most of them also require the -lm option to >>>> correctly handle code that uses <math.h>, and gcc also requires >>>> -pedantic. There was an extended discussion of this issue a few >>>> years ago in this newsgroup. In the end, only two very obscure >>>> compilers were identified that supposedly fully conformed in >>>> their default mode - and given how obscure they were, that >>>> conclusion might have simply been the result of nobody being >>>> aware of the the ways that they failed to conform. >>>> >>> >>> When they support multiple versions of the standard, they need to >>> know which version of the standard to use. >> >> And so they require a switch, without which they are non-conforming >> to any standard (or at least that's the case for gcc). >> >>> But -lm is a linker parameter, not compiler. >> >> Yes. Since we have been using the word "compiler" it's a >> reasonable objection. Nevertheless, if we take the linker out of >> the equation, *no* compiler is conforming, because to leave out the >> linker necessarily means leaving out TP8! >> >> And if we put the linker back into the equation, gcc fails to >> conform even when told to by -std=c??, unless the additional magic >> rune -lm is added, just as James explained to you already. >> > > The C standard doesn't say anything about the linker (although it > does extensively discuss linkage) or how libraries are linked in. The C Standard has this to say about linking: "8. All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment." So it says that linking *must happen*, conceptually at the very least (as with an interpreter). If the linking step is omitted, the implementation is not a conforming implementation. In other words, the program must be able to execute, or there's no point. > But I would guess the reason for the -lm flag would be you might want > to use libm, or you might have another library you want for the math > functions. But I didn't write the compiler, so I don't know what they > were thinking. The reason, for the purposes of this discussion, *doesn't matter*. What matters is that gcc is an example of a compiler that is not conforming by default. >>> And I always thought gcc was -pedantic. I didn't realize it >>> needed a flag to make it even more so. >> >> gcc in default mode is remarkably forgiving, as long as you don't >> sin (or cos, or tan, or anything else math.h-y). >> > > Yes, sometimes too forgiving. Again, this is in direct contrast to your claim that "being conforming doesn't mean they have to flag non-conforming code". In fact, it certainly does mean that, and if gcc is too forgiving, then gcc is again failing to conform. You claimed that most compilers are conforming in their default mode, but so far you have not produced the names of any compilers that do conform in their default mode. Let me tell you some that don't: gcc Borland Visual Studio Code Warrior C/370 LE370 Can you name some that do? Or one, even? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 21:47 -0500 |
| Message-ID | <o2d5te$i66$1@jstuckle.eternal-september.org> |
| In reply to | #98384 |
On 12/8/2016 11:16 AM, Richard Heathfield wrote: > On 08/12/16 15:44, Jerry Stuckle wrote: >> On 12/8/2016 9:22 AM, Richard Heathfield wrote: >>> On 08/12/16 14:13, Jerry Stuckle wrote: >>>> On 12/7/2016 6:33 PM, jameskuyper@verizon.net wrote: >>>>> On Wednesday, December 7, 2016 at 3:13:27 PM UTC-5, Jerry >>>>> Stuckle wrote: >>>>>> On 12/7/2016 12:40 PM, Keith Thompson wrote: >>>>> ... >>>>>>> Most C compilers are not conforming by default, and require >>>>>>> some added options to make them (atte >>>>> I >>>>>>> >>>>>> >>>>>> Why do you say that? There is nothing that says a compiler >>>>>> can't add features, as long as it does everything the >>>>>> standard says it does. >>>>> >>>>> ... and doesn't do anything the standard says is shouldn't do. >>>>> However, it turns out that most compilers do in fact fail to do >>>>> something required by the standard, or do something prohibited >>>>> by the standard, when invoked in their default mode. The >>>>> compilers I've used most frequently over the past couple of >>>>> decades all take an -ansi option that puts them in C90 mode; >>>>> without that option, they don't fully conform to any version of >>>>> the C standard. Most of them also require the -lm option to >>>>> correctly handle code that uses <math.h>, and gcc also requires >>>>> -pedantic. There was an extended discussion of this issue a few >>>>> years ago in this newsgroup. In the end, only two very obscure >>>>> compilers were identified that supposedly fully conformed in >>>>> their default mode - and given how obscure they were, that >>>>> conclusion might have simply been the result of nobody being >>>>> aware of the the ways that they failed to conform. >>>>> >>>> >>>> When they support multiple versions of the standard, they need to >>>> know which version of the standard to use. >>> >>> And so they require a switch, without which they are non-conforming >>> to any standard (or at least that's the case for gcc). >>> >>>> But -lm is a linker parameter, not compiler. >>> >>> Yes. Since we have been using the word "compiler" it's a >>> reasonable objection. Nevertheless, if we take the linker out of >>> the equation, *no* compiler is conforming, because to leave out the >>> linker necessarily means leaving out TP8! >>> >>> And if we put the linker back into the equation, gcc fails to >>> conform even when told to by -std=c??, unless the additional magic >>> rune -lm is added, just as James explained to you already. >>> >> >> The C standard doesn't say anything about the linker (although it >> does extensively discuss linkage) or how libraries are linked in. > > The C Standard has this to say about linking: "8. All external object > and function references are resolved. Library components are linked to > satisfy external references to functions and objects not defined in the > current translation. All such translator output is collected into a > program image which contains information needed for execution in its > execution environment." > > So it says that linking *must happen*, conceptually at the very least > (as with an interpreter). If the linking step is omitted, the > implementation is not a conforming implementation. In other words, the > program must be able to execute, or there's no point. > It doesn't say there has to be a link step. It just states that the external references must be resolved - not how the resolution is done. It could be done by the compiler, for instance. But then the linker is not part of C - it is common to all languages, so a C standard could not define it. >> But I would guess the reason for the -lm flag would be you might want >> to use libm, or you might have another library you want for the math >> functions. But I didn't write the compiler, so I don't know what they >> were thinking. > > The reason, for the purposes of this discussion, *doesn't matter*. What > matters is that gcc is an example of a compiler that is not conforming > by default. > The standard also doesn't say it has to be conforming "by default". Just that it has to be conforming. The standard also doesn't say the compiler must have a means of compiling only (-c in gcc). But all compilers do. >>>> And I always thought gcc was -pedantic. I didn't realize it >>>> needed a flag to make it even more so. >>> >>> gcc in default mode is remarkably forgiving, as long as you don't >>> sin (or cos, or tan, or anything else math.h-y). >>> >> >> Yes, sometimes too forgiving. > > Again, this is in direct contrast to your claim that "being conforming > doesn't mean they have to flag non-conforming code". In fact, it > certainly does mean that, and if gcc is too forgiving, then gcc is again > failing to conform. > I already agreed that you would have to specify which standard would be followed for a compiler which supports multiple standards. But you can't get by that, can you? Reading comprehension problems? But then the standard also doesn't say the compiler must be conforming in its default mode, does it? > You claimed that most compilers are conforming in their default mode, > but so far you have not produced the names of any compilers that do > conform in their default mode. > I already agreed that you would have to specify which standard would be followed for a compiler which supports multiple standards. But you can't get by that, can you? Reading comprehension problems? But then the standard also doesn't say the compiler must be conforming in its default mode, does it? > Let me tell you some that don't: > > gcc > Borland > Visual Studio > Code Warrior > C/370 > LE370 > > Can you name some that do? Or one, even? > I already agreed that you would have to specify which standard would be followed for a compiler which supports multiple standards. But you can't get by that, can you? Reading comprehension problems? But then the standard also doesn't say the compiler must be conforming in its default mode, does it? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-08 20:16 -0800 |
| Message-ID | <e40ed64b-ff5f-4aa7-b93e-990e84a6186e@googlegroups.com> |
| In reply to | #98437 |
On Thursday, December 8, 2016 at 9:47:35 PM UTC-5, Jerry Stuckle wrote: > On 12/8/2016 11:16 AM, Richard Heathfield wrote: > > On 08/12/16 15:44, Jerry Stuckle wrote: ... > But then the linker is not part of C - it is common to all languages, so > a C standard could not define it. The C standard defines what a conforming implementation of C does. Part of what it's required to do is done, on most platforms, by a linker. The C standard imposes no requirements on the linker itself. But if a implementation cannot meet the C standard's requirements while using th standard linker for a given platform, because that linker doesn't handle linkage in a way that's compatible with the C standard's requirements, then a conforming implementation of C for that platform would have to provide a non-standard linker of it's own. This is, in fact, what happens with C++ on many platforms. If such a platform did not allow the use of non-standard linkers, then a fully conforming implementation of C would not be possible for that platform. ... > The standard also doesn't say it has to be conforming "by default". People have pointed out, correctly, that most implementations don't conform in their default mode, but no one has suggested that this violates any requirement of the standard. That's just a straw man argument of your own invention. > Just that it has to be conforming. Actually, it doesn't even say that. It only defines what being a conforming implementation means. It nowhere imposes any requirement that anything, anywhere in the universe, is required to match that definition. Something advertised as conforming to the C standard should in fact conform, but that's not because the standard says so, but because the false advertising laws say so. > The standard also doesn't say the compiler must have a means of > compiling only (-c in gcc). But all compilers do. I've used compilers which could only compile - they had no capability of calling the linker to link the program together. You had to do that explicitly yourself. There was no need for a -c option on such a compiler, because it corresponded to the default mode of that compiler. > I already agreed that you would have to specify which standard would be > followed for a compiler which supports multiple standards. But you > can't get by that, can you? Reading comprehension problems? I agree - but it's a reading comprehension issue on your part. The statement you initially objected to was about the behavior of compilers in their default mode. By definition, that's the mode in which no options are specified. In particular, that means it's a mode in which no option is used to tell the compiler to conform to a particular version of the standard. A compiler that fully conforms to some version of the standard only when such an option is selected does not qualify as a counter-example to Keith's claim, because it's not in default mode. There's other problems with your statement as well. This isn't just about compilers that support multiple versions of the standard. There are compilers that only conform to a single version of the standard. Even those compilers don't conform to any version of the standard in default mode - they only conform when you select the options that put them into conforming mode. Furthermore, you say that "you have to specify which standard would be followed". That's not inherently true. It would have been entirely possible to design a compiler that only fully conforms to C99 or C2011 when you select the appropriate options, but which fully conforms to C90 if you select no options. It's an odd fact, but apparently true, that there are no such compilers - at least, no one monitoring this newsgroup (or comp.std.c) has nominated a compiler as having that feature, without having the claim almost immediately disproved. And it's precisely that odd fact that Keith was talking about, which you objected to.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-09 11:19 +0100 |
| Message-ID | <o2e0c9$l40$1@dont-email.me> |
| In reply to | #98450 |
On 09/12/16 05:16, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:47:35 PM UTC-5, Jerry Stuckle wrote: <snip> >> The standard also doesn't say the compiler must have a means of >> compiling only (-c in gcc). But all compilers do. > > I've used compilers which could only compile - they had no capability of > calling the linker to link the program together. You had to do that explicitly > yourself. There was no need for a -c option on such a compiler, because it > corresponded to the default mode of that compiler. > And I have used compilers that can only go directly to a fully linked binary - they don't support compilation of individual C files, generation of assembly files, or a separate linking stage. Typical cases include compilers where you always use "whole program optimisation" because the generated code for brain-dead little microcontrollers is too awful without it, and cases where the compiler is locked to a limited size of compilation and the vendor does not want you to use the generated assembly as a way of cheating. Usually when someone says "all compilers do...", they are wrong. Perhaps "/most/ compilers do...", but there are usually exceptions somewhere.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-09 08:00 -0800 |
| Message-ID | <388c4205-e3f5-45af-961d-ce6bb8147322@googlegroups.com> |
| In reply to | #98450 |
On Thursday, December 8, 2016 at 10:16:27 PM UTC-6, james...@verizon.net wrote: > The C standard defines what a conforming implementation of C does. Part of what > it's required to do is done, on most platforms, by a linker. The C standard > imposes no requirements on the linker itself. But if a implementation cannot > meet the C standard's requirements while using th standard linker for a given > platform, because that linker doesn't handle linkage in a way that's compatible > with the C standard's requirements, then a conforming implementation of C for > that platform would have to provide a non-standard linker of it's own. This is, > in fact, what happens with C++ on many platforms. If such a platform did not > allow the use of non-standard linkers, then a fully conforming implementation > of C would not be possible for that platform. Very few real C implementations are sold, since a C implementation would need to include not only software but also the execution platform necessary to run the program in question. People might sell collections of software which would allow commonplace machines to behave as C implementations, but in most cases the software that translates C code will supplied by a different entity from the execution platform. C is most useful when not viewed formally as a "language" (i.e. mapping between source texts and behaviors), but rather as a mapping between execution platform descriptions and languages. While it's possible to have a compiler which targets one platform emulate the behavior of another (e.g. one could write a compiler for x86 which stored all integers in big-endian format, to allow C code written for the 68000 to be used on x86 machines), it is often more useful for general-purpose compilers to behave in a fashion consistent with the underlying platform, both on issues where all platforms are required to define behaviors, and on those where many platforms can define useful behaviors but some platforms might not be able to. The design of C's integer types is sensible if the purpose is to make it possible for every platform to have a usable language. It is not designed to allow programs to be written in multi-platform fashion. I'm not sure where the notion that C programs which aren't intended to be used on one specific platform should be usable on *all* allowable C platforms came from, but I'd suggest it would be far more useful to recognize a class of commonplace features which most platforms can support, and recognize that platforms which don't support such features will only be able to use code that doesn't require them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-13 13:10 -0800 |
| Message-ID | <kfnshprilh4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98543 |
supercat@casperkitty.com writes: > On Thursday, December 8, 2016 at 10:16:27 PM UTC-6, james...@verizon.net wrote: >> The C standard defines what a conforming implementation of C does. >> Part of what it's required to do is done, on most platforms, by a >> linker. The C standard imposes no requirements on the linker >> itself. But if a implementation cannot meet the C standard's >> requirements while using th standard linker for a given platform, >> because that linker doesn't handle linkage in a way that's >> compatible with the C standard's requirements, then a conforming >> implementation of C for that platform would have to provide a >> non-standard linker of it's own. This is, in fact, what happens >> with C++ on many platforms. If such a platform did not allow the >> use of non-standard linkers, then a fully conforming implementation >> of C would not be possible for that platform. > > Very few real C implementations are sold, since a C implementation > would need to include not only software but also the execution > platform necessary to run the program in question. A common misconception. The C standard explicitly places such things as hardware and operating system (aka "data processing system") outside the realm of implementation, in section 1 of the ISO standard, and has since the initial version in 1990.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-13 13:55 -0800 |
| Message-ID | <9f4512be-40bb-4d4f-abb6-6d0bffb5171e@googlegroups.com> |
| In reply to | #99261 |
On Tuesday, December 13, 2016 at 4:10:39 PM UTC-5, Tim Rentsch wrote: > supercat@casperkitty.com writes: > > > On Thursday, December 8, 2016 at 10:16:27 PM UTC-6, james...@verizon.net wrote: > >> The C standard defines what a conforming implementation of C does. > >> Part of what it's required to do is done, on most platforms, by a > >> linker. The C standard imposes no requirements on the linker > >> itself. But if a implementation cannot meet the C standard's > >> requirements while using th standard linker for a given platform, > >> because that linker doesn't handle linkage in a way that's > >> compatible with the C standard's requirements, then a conforming > >> implementation of C for that platform would have to provide a > >> non-standard linker of it's own. This is, in fact, what happens > >> with C++ on many platforms. If such a platform did not allow the > >> use of non-standard linkers, then a fully conforming implementation > >> of C would not be possible for that platform. > > > > Very few real C implementations are sold, since a C implementation > > would need to include not only software but also the execution > > platform necessary to run the program in question. > > A common misconception. The C standard explicitly places such > things as hardware and operating system (aka "data processing > system") outside the realm of implementation, in section 1 of > the ISO standard, and has since the initial version in 1990. True. However, the C standard does define an implementation as a "particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment". Note the phrase "running". An implementation is NOT an implementation except when it it running. Therefore, while the "data processing system" is not part of the implementation, is is needed in order for something else to qualify as an implementation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-15 01:13 -0800 |
| Message-ID | <kfnr359ftcm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99272 |
jameskuyper@verizon.net writes: > On Tuesday, December 13, 2016 at 4:10:39 PM UTC-5, Tim Rentsch wrote: >> supercat@casperkitty.com writes: >> >>> On Thursday, December 8, 2016 at 10:16:27 PM UTC-6, james...@verizon.net wrote: >>>> The C standard defines what a conforming implementation of C does. >>>> Part of what it's required to do is done, on most platforms, by a >>>> linker. The C standard imposes no requirements on the linker >>>> itself. But if a implementation cannot meet the C standard's >>>> requirements while using th standard linker for a given platform, >>>> because that linker doesn't handle linkage in a way that's >>>> compatible with the C standard's requirements, then a conforming >>>> implementation of C for that platform would have to provide a >>>> non-standard linker of it's own. This is, in fact, what happens >>>> with C++ on many platforms. If such a platform did not allow the >>>> use of non-standard linkers, then a fully conforming implementation >>>> of C would not be possible for that platform. >>> >>> Very few real C implementations are sold, since a C implementation >>> would need to include not only software but also the execution >>> platform necessary to run the program in question. >> >> A common misconception. The C standard explicitly places such >> things as hardware and operating system (aka "data processing >> system") outside the realm of implementation, in section 1 of >> the ISO standard, and has since the initial version in 1990. > > True. However, the C standard does define an implementation as a > "particular set of software, running in a particular translation > environment under particular control options, that performs > translation of programs for, and supports execution of functions in, > a particular execution environment". Note the phrase "running". An > implementation is NOT an implementation except when it it running. > Therefore, while the "data processing system" is not part of the > implementation, is is needed in order for something else to qualify > as an implementation. I think we are assuming somewhat different semantic contexts for our respective statements. Let me see if I can clarify that so things don't get confused. I think your comments are meant in a semantic context of how the text of the Standard should be read, parsed, and interpreted. Another way of saying this is that your comments are (I think) made in the sense of what the Standard "really means" or "literally says". My comments are meant in a semantic context of what WG14 views the Standard as saying. In this semantic context the actual text can give an indication of what is meant, but the only thing that counts is what WG14 thinks it means. I find it useful, in comp.lang.c, to try to operate in this semantic context rather than a different one. Does this assessment seem right to you? If so, I believe we are working in basically disjoint universes, and there isn't much more to say. If that doesn't seem right, or if you want to say something specifically about what WG14 would say on the matter, then please continue.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-15 07:02 -0800 |
| Message-ID | <17e48f9d-cf45-41d0-89b0-fecd970dee65@googlegroups.com> |
| In reply to | #99465 |
On Thursday, December 15, 2016 at 4:13:20 AM UTC-5, Tim Rentsch wrote: > jameskuyper@verizon.net writes: > > > On Tuesday, December 13, 2016 at 4:10:39 PM UTC-5, Tim Rentsch wrote: > >> supercat@casperkitty.com writes: ... > >>> Very few real C implementations are sold, since a C implementation > >>> would need to include not only software but also the execution > >>> platform necessary to run the program in question. > >> > >> A common misconception. The C standard explicitly places such > >> things as hardware and operating system (aka "data processing > >> system") outside the realm of implementation, in section 1 of > >> the ISO standard, and has since the initial version in 1990. > > > > True. However, the C standard does define an implementation as a > > "particular set of software, running in a particular translation > > environment under particular control options, that performs > > translation of programs for, and supports execution of functions in, > > a particular execution environment". Note the phrase "running". An > > implementation is NOT an implementation except when it it running. > > Therefore, while the "data processing system" is not part of the > > implementation, is is needed in order for something else to qualify > > as an implementation. > > I think we are assuming somewhat different semantic contexts for > our respective statements. ... I thought that the difference between our statements was only that we were addressing different aspects of the situation. I was not disagreeing with you, just addressing different but closely related issues. > ... Let me see if I can clarify that so > things don't get confused. Too late, I think. I'm thoroughly confused about the connection between the particular issue I described above, and the abstract issue you describe below. I think I understand both issues, I just don't see the connection. Could you explain it? > I think your comments are meant in a semantic context of how the > text of the Standard should be read, parsed, and interpreted. > Another way of saying this is that your comments are (I think) > made in the sense of what the Standard "really means" or > "literally says". > > My comments are meant in a semantic context of what WG14 views > the Standard as saying. In this semantic context the actual text > can give an indication of what is meant, but the only thing that > counts is what WG14 thinks it means. I find it useful, in > comp.lang.c, to try to operate in this semantic context rather > than a different one. > > Does this assessment seem right to you? ... Your description of my point of view seems reasonably correct. Only you can know about the correctness of your description of your own point of view. You're describing attitudes you have that I did not realize you were holding, but I see no reason to doubt you. > ... If so, I believe we are > working in basically disjoint universes, and there isn't much > more to say. If that doesn't seem right, or if you want to > say something specifically about what WG14 would say on the > matter, then please continue. In a conversation I had with Doug Gwyn several years ago, I described a similar contrast of concepts in slightly different terms. There were two different attitudes about the standard being expressed. One was that the standard means what it's actual words say, and that if there's a discrepancy between those words and what the committee intended, then it means the standard is defective. The other was that the standard is what the committee intended it to say, and the standard document is just a means of communicating that intent. If there's a discrepancy between that intent and the actual words of the standa, it's a failure to correctly communicate the meaning of the standard, rather than a defect in the standard itself. I find that first point of view more reasonable, because I lack the mind-reading ability that Doug called "common sense". More to the point, I seriously doubt that the committee members are actually able to read each other's minds, either, even if they might think otherwise. For the committee members, as for the rest of us, the only way they can know for sure what the standard actually means is by using words to communicate with the other members - and words that have been written down are a much more reliable source than those that have only been spoken. And even with the written words, the only way an individual committee member can be sure that the written words match the intent of the abstract entity called "the Committee" is by seeing how the members voted on approving those words. However, I also pointed out to Doug that it doesn't really matter which model you use. Either way, any discrepancy between the committee's intent and the actual words is a problem that should be fixed by changing the document (though not necessarily at a high priority, if the discrepancy is minor or seldom causes misunderstandings).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-15 19:56 -0800 |
| Message-ID | <kfn1sx8frxn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99502 |
jameskuyper@verizon.net writes: > On Thursday, December 15, 2016 at 4:13:20 AM UTC-5, Tim Rentsch wrote: >> jameskuyper@verizon.net writes: >> >>> On Tuesday, December 13, 2016 at 4:10:39 PM UTC-5, Tim Rentsch wrote: >>>> supercat@casperkitty.com writes: > > ... > >>>>> Very few real C implementations are sold, since a C implementation >>>>> would need to include not only software but also the execution >>>>> platform necessary to run the program in question. >>>> >>>> A common misconception. The C standard explicitly places such >>>> things as hardware and operating system (aka "data processing >>>> system") outside the realm of implementation, in section 1 of >>>> the ISO standard, and has since the initial version in 1990. >>> >>> True. However, the C standard does define an implementation as a >>> "particular set of software, running in a particular translation >>> environment under particular control options, that performs >>> translation of programs for, and supports execution of functions in, >>> a particular execution environment". Note the phrase "running". An >>> implementation is NOT an implementation except when it it running. >>> Therefore, while the "data processing system" is not part of the >>> implementation, is is needed in order for something else to qualify >>> as an implementation. >> >> I think we are assuming somewhat different semantic contexts for >> our respective statements. ... > > I thought that the difference between our statements was only that > we were addressing different aspects of the situation. I was not > disagreeing with you, just addressing different but closely > related issues. Okay. I didn't respond directly to what you were saying, because I thought trying to do that before getting the context issue straightened out would likely lead to confusion or frustration. (I have adjusted some of the spacing in the quoted text to make it easier for my newsreader to process it without complaint.) >> ... Let me see if I can clarify that so >> things don't get confused. > > Too late, I think. I'm thoroughly confused about the connection > between the particular issue I described above, and the abstract > issue you describe below. I think I understand both issues, I > just don't see the connection. Could you explain it? I think so. Let me try. The point you bring up is unrelated to the matter of semantic contexts, or perhaps "perspectives" is a better word, _except_ that our having different perspectives would get in the way of communicating effectively about the other issues mentioned previously (ie, one by you and one by me). The different perspectives affect how each of us expects others will hear comments made about the ISO standard. For example, when I say "The Standard requires X" what I mean is something like "WG14 regards the Standard as requiring X" or some other similar wording along the same lines, eg, "WG14 believes ..." or "WG14 thinks ...". Conversely, when you say (and here I am guessing, so please say something if my guesses are off in any way) "The Standard requires X" what you mean is something like "the text of the Standard, along with the rules of the English language, syntax and semantics, taken all together imply the text should be interpreted to mean that X is required." Forgive me if my wording is a bit clumsy, I am trying to accurately capture your intention while also being careful to not be sloppy in my use of phrasing. Assuming the foregoing is correct, to a first approximation the two kinds of statements have nothing to do with each other. When you say something, you aren't saying anything about what WG14 thinks, and when I say something, I'm not saying anything about what the rules of English say about how the text should be interpreted. The two perspectives are in effect examining different universes, with no elements in common, so there is neither "agreement" nor "disagreement" - just unrelated statements. Does that make sense? I might add that statements made from one perspective might say something indirectly about statements made from the other perspective, but for now I'm not concerned with any such indirect implications. I think it's better to keep things simple and consider only direct interactions. >[...] > >> ... If so, I believe we are >> working in basically disjoint universes, and there isn't much >> more to say. If that doesn't seem right, or if you want to >> say something specifically about what WG14 would say on the >> matter, then please continue. > > In a conversation I had with Doug Gwyn several years ago, I > described a similar contrast of concepts in slightly different > terms. There were two different attitudes about the standard > being expressed. One was that the standard means what its actual > words say, and that if there's a discrepancy between those words > and what the committee intended, then it means the standard is > defective. The other was that the standard is what the committee > intended it to say, and the standard document is just a means of > communicating that intent. If there's a discrepancy between that > intent and the actual words of the standa, it's a failure to > correctly communicate the meaning of the standard, rather than a > defect in the standard itself. Yes, this is similar to what I have described as the differences in our perspectives. One key difference: I don't think either perspective is right or wrong, it's just a stance one chooses to adopt for how their statements are meant to be heard. In this newsgroup, I usually take the "WG14 thinks..." perspective. In comp.std.c, I am more likely to take the "the rules of English imply ..." perspective. In neither case am I saying how my statements "should" be heard, but rather how I want or expect them to be heard. Do you see what I'm getting at? > I find that first point of view more reasonable, because I lack the > mind-reading ability that Doug called "common sense". More to the > point, I seriously doubt that the committee members are actually > able to read each other's minds, either, even if they might think > otherwise. For the committee members, as for the rest of us, the > only way they can know for sure what the standard actually means is > by using words to communicate with the other members - and words > that have been written down are a much more reliable source than > those that have only been spoken. And even with the written words, > the only way an individual committee member can be sure that the > written words match the intent of the abstract entity called "the > Committee" is by seeing how the members voted on approving those > words. Here I think you are touching on a larger issue, to an extent that I'm not really sure how to express it. I agree that how people approach understanding what the Standard requires is different for different people, and it is often difficult to resolve different understandings, especially in the case where the people involved have different ideas about how the Standard should be understood to begin with. Right now I don't know that I have any further intelligent comment to make on the matter. > However, I also pointed out to Doug that it doesn't really matter > which model you use. Either way, any discrepancy between the > committee's intent and the actual words is a problem that should be > fixed by changing the document (though not necessarily at a high > priority, if the discrepancy is minor or seldom causes > misunderstandings). Basically I think I agree with this. In this arena I tend to take an operational viewpoint - if a reasonable number of people (and reasonable people) misunderstand what the committee thinks the Standard requires, or if people can't agree about what the Standard requires, then there is a defect in the text of the Standard, and that should be repaired by altering the text - adding to it, deleting some of it, changing some of it, or potentially all three. How important it is to do that depends on a lot of different factors, and certainly not all problems are equally important to address. I guess the key point for me is the seriousness of a problem depends on the magnitude of the misunderstandings that people have - the more people there are who misunderstand or don't understand, or the greater the level of min/non-understanding, the more important it is to address the matter by changing the document. Does that sound pretty much like what you are saying?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-18 10:00 -0800 |
| Message-ID | <05e7677b-0757-4362-a0dc-addbfb9e5a2f@googlegroups.com> |
| In reply to | #99502 |
On Thursday, December 15, 2016 at 9:02:18 AM UTC-6, james...@verizon.net wrote: > In a conversation I had with Doug Gwyn several years ago, I described a similar > contrast of concepts in slightly different terms. There were two different > attitudes about the standard being expressed. One was that the standard means > what it's actual words say, and that if there's a discrepancy between those words and what the committee intended, then it means the standard is defective. The other was that the standard is what the committee intended it to say, and > the standard document is just a means of communicating that intent. If there's > a discrepancy between that intent and the actual words of the standa, it's a > failure to correctly communicate the meaning of the standard, rather than a > defect in the standard itself. > > I find that first point of view more reasonable, because I lack the mind-reading > ability that Doug called "common sense". More to the point, I seriously doubt > that the committee members are actually able to read each other's minds, > either, even if they might think otherwise. For the committee members, as for > the rest of us, the only way they can know for sure what the standard actually > means is by using words to communicate with the other members - and words that > have been written down are a much more reliable source than those that have > only been spoken. And even with the written words, the only way an individual > committee member can be sure that the written words match the intent of the > abstract entity called "the Committee" is by seeing how the members voted on > approving those words. > However, I also pointed out to Doug that it doesn't really matter which model > you use. Either way, any discrepancy between the committee's intent and the > actual words is a problem that should be fixed by changing the document > (though not necessarily at a high priority, if the discrepancy is minor or seldom causes misunderstandings). The purpose of the C89 Standard was not to create a new language, nor even augment an existing one, but rather to document a language that *already existed*, while trying to ensure--as much as possible--that any platform that has a C implementation and code written to use use it, will be able to have a conforming C implementation process that code just as effectively as the existing one. The C89 Standard made no attempt to be exhaustive in describing all of the things that every existing implementation supported at every imaginable implementation would naturally support. It focused mainly on things which some platforms might not naturally support, saying for each either that an implementation would be required to support a certain construct at any cost [e.g. unsigned math must use a power-of-two modulus] or that platforms where supporting something would be expensive need not support it. A "common sense interpretation" of the Standard doesn't require mind reading so much as it requires an acceptance of the principle that the C89 Standard was not intended to markedly change the language, nor imply that constructs which were portable among existing implementations for architectures with certain features should not continue to be portable among quality implementations for such architectures. In cases where continuing support for a behavior that had been "free" would become costly, the logical way to proceed forward would be to deprecate the behavior, provide options to waive support for it, and note that failing to exercise such options may have some performance cost. Code which relies upon the behavior shouldn't be viewed as "broken", but instead subjected to a cost-benefit analysis, weighing the value of the performance gained versus the cost of the foregone optimizations. If support for a construct would allow a 5x speedup in time-critical loops, while foregoing optimizations that could have achieved a 5% improvement, common-sense would suggest that a quality compiler should support the construct. Indeed, even if the construct wouldn't offer a speed-up on the compiler's target platform but would offer a 5x speed-up on other similar platforms, support for the construct may facilitate porting of code written for those other platforms. In many cases the optimization costs of exploiting platform features is greater on faster machines than on slower ones, but that performance is often more of an issue on slower machines than on faster ones. Thus, it often makes sense for a program that will be used on both slow and fast machines to exploit features that will improve performance on the former, even if they impede performance on the latter. Having compilers for the faster machines support such constructs, even at a significant performance cost, will greatly assist the writing of programs that can run efficiently on slow machines and correctly on fast machines.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-14 11:45 -0800 |
| Message-ID | <4c296023-6677-4382-853d-fcaa5fa61220@googlegroups.com> |
| In reply to | #99261 |
On Tuesday, December 13, 2016 at 3:10:39 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > Very few real C implementations are sold, since a C implementation > > would need to include not only software but also the execution > > platform necessary to run the program in question. > > A common misconception. The C standard explicitly places such > things as hardware and operating system (aka "data processing > system") outside the realm of implementation, in section 1 of > the ISO standard, and has since the initial version in 1990. Section 1.2 says that the Standard exercises no authority over the mechanism by which various things are accomplished; that does not mean that something can be a conforming C implementation without being able to actually to run any program that it would be required to accept. The combination of a compiler that generates some form of machine-code files and a system that can execute such files could be a conforming C implementation. The compiler by itself, without a means of running the generated machine-code files, could not be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-14 12:14 -0800 |
| Message-ID | <lnvaummfow.fsf@kst-u.example.com> |
| In reply to | #99383 |
supercat@casperkitty.com writes:
> On Tuesday, December 13, 2016 at 3:10:39 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>> > Very few real C implementations are sold, since a C implementation
>> > would need to include not only software but also the execution
>> > platform necessary to run the program in question.
>>
>> A common misconception. The C standard explicitly places such
>> things as hardware and operating system (aka "data processing
>> system") outside the realm of implementation, in section 1 of
>> the ISO standard, and has since the initial version in 1990.
>
> Section 1.2 says that the Standard exercises no authority over the
> mechanism by which various things are accomplished; that does not
> mean that something can be a conforming C implementation without
> being able to actually to run any program that it would be required
> to accept. The combination of a compiler that generates some form
> of machine-code files and a system that can execute such files could
> be a conforming C implementation. The compiler by itself, without a
> means of running the generated machine-code files, could not be.
Most computers cannot operate without a power supply. A power plant is
not part of the C 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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-15 01:24 -0800 |
| Message-ID | <kfnmvfxfstq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99383 |
supercat@casperkitty.com writes:
> On Tuesday, December 13, 2016 at 3:10:39 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>> Very few real C implementations are sold, since a C implementation
>>> would need to include not only software but also the execution
>>> platform necessary to run the program in question.
>>
>> A common misconception. The C standard explicitly places such
>> things as hardware and operating system (aka "data processing
>> system") outside the realm of implementation, in section 1 of
>> the ISO standard, and has since the initial version in 1990.
>
> Section 1.2 says that the Standard exercises no authority over the
> mechanism by which various things are accomplished; [...]
No, it doesn't. It would help you to try improving your ability
to read without applying your own filters so strongly.
First please read the comments in my response to James Kuyper.
The key passage in section 1 paragraph 2 is the reference to
all minimal requirements of a data-processing system that is
capable of supporting a conforming implementation.
I believe this shows that WG14 regards "data-processing system"
and "implementation" as separate and distinct elements. Do you
agree with that impression? Or do you think WG14 has a different
opinion on the matter?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-15 08:02 -0800 |
| Message-ID | <a05d8241-40e7-420e-92f6-bcc9af7124d0@googlegroups.com> |
| In reply to | #99467 |
On Thursday, December 15, 2016 at 3:24:40 AM UTC-6, Tim Rentsch wrote: > The key passage in section 1 paragraph 2 is the reference to > > all minimal requirements of a data-processing system that is > capable of supporting a conforming implementation. > > I believe this shows that WG14 regards "data-processing system" > and "implementation" as separate and distinct elements. Do you > agree with that impression? Or do you think WG14 has a different > opinion on the matter? If I offer a pair of black boxes such that feeding a program into the first yields a bunch of seemingly-arbitrary bytes, but feeding those bytes into the second yields the output the program would be required to produce, would that pair of boxes be a conforming implementation? I would suggest that it would. If I were to only offer you the first box, however, would you consider that to be a conforming C implementation? If it would, how would you distinguish it from a cryptographic pseudo-random generator that uses the input source text as its seed? I would suggest that for something to be a conforming C implementation, it must include everything necessary to take input in some text form, and produce something that can be interpreted as the proper output. The Standard doesn't describe a C implementation as something which produces a collection of information that, when fed to some other unspecified device, will cause that device to produce the required output. It describes the C implementation as something that produces the required output itself.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-15 12:10 -0800 |
| Message-ID | <lny3zhkl7m.fsf@kst-u.example.com> |
| In reply to | #99511 |
supercat@casperkitty.com writes:
> On Thursday, December 15, 2016 at 3:24:40 AM UTC-6, Tim Rentsch wrote:
>> The key passage in section 1 paragraph 2 is the reference to
>>
>> all minimal requirements of a data-processing system that is
>> capable of supporting a conforming implementation.
>>
>> I believe this shows that WG14 regards "data-processing system"
>> and "implementation" as separate and distinct elements. Do you
>> agree with that impression? Or do you think WG14 has a different
>> opinion on the matter?
>
> If I offer a pair of black boxes such that feeding a program into the
> first yields a bunch of seemingly-arbitrary bytes, but feeding those
> bytes into the second yields the output the program would be required
> to produce, would that pair of boxes be a conforming implementation?
> I would suggest that it would.
>
> If I were to only offer you the first box, however, would you consider
> that to be a conforming C implementation? If it would, how would you
> distinguish it from a cryptographic pseudo-random generator that uses
> the input source text as its seed?
If I understand these "black boxes" correctly, I would consider the
first box to be a conforming C implementation that requires the second
box (or something equivalent) to function.
> I would suggest that for something to be a conforming C implementation,
> it must include everything necessary to take input in some text form,
> and produce something that can be interpreted as the proper output.
> The Standard doesn't describe a C implementation as something which
> produces a collection of information that, when fed to some other
> unspecified device, will cause that device to produce the required
> output. It describes the C implementation as something that produces
> the required output itself.
I have a C implementation running on my computer (along with an
operating system and a lot of other software and data). Neither my
computer nor the C implementation will operate without electrical power.
The power plant that provides me with electricity is not part of the C
implementation, even though it or something like it is a prerequisite
for the C implementation to work. Neither is the Sun.
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2016-12-16 20:00 -0800 |
| Message-ID | <MPG.32be58264db8d4f0129@news.eternal-september.org> |
| In reply to | #99556 |
Keith Thompson wrote: > supercat@casperkitty.com writes: > > Tim Rentsch wrote: > >> The key passage in section 1 paragraph 2 is the reference to > >> > >> all minimal requirements of a data-processing system that is > >> capable of supporting a conforming implementation. > >> > >> I believe this shows that WG14 regards "data-processing system" > >> and "implementation" as separate and distinct elements. Do you > >> agree with that impression? Or do you think WG14 has a different > >> opinion on the matter? > > > > If I offer a pair of black boxes such that feeding a program into the > > first yields a bunch of seemingly-arbitrary bytes, but feeding those > > bytes into the second yields the output the program would be required > > to produce, would that pair of boxes be a conforming implementation? > > I would suggest that it would. > > > > If I were to only offer you the first box, however, would you consider > > that to be a conforming C implementation? If it would, how would you > > distinguish it from a cryptographic pseudo-random generator that uses > > the input source text as its seed? > > If I understand these "black boxes" correctly, I would consider the > first box to be a conforming C implementation that requires the second > box (or something equivalent) to function. Does your answer change depending on whether the output from the first box is the result of translation phase 3, 4, 7, or 8, which is unknowable? (I guess from your answer that you believe the output of the first box is the result of translation phase 8.)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 11:05 -0500 |
| Message-ID | <o2ekl9$tcu$1@jstuckle.eternal-september.org> |
| In reply to | #98450 |
On 12/8/2016 11:16 PM, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:47:35 PM UTC-5, Jerry Stuckle wrote: >> On 12/8/2016 11:16 AM, Richard Heathfield wrote: >>> On 08/12/16 15:44, Jerry Stuckle wrote: > ... >> But then the linker is not part of C - it is common to all languages, so >> a C standard could not define it. > > The C standard defines what a conforming implementation of C does. Part of what > it's required to do is done, on most platforms, by a linker. The C standard > imposes no requirements on the linker itself. But if a implementation cannot > meet the C standard's requirements while using th standard linker for a given > platform, because that linker doesn't handle linkage in a way that's compatible > with the C standard's requirements, then a conforming implementation of C for > that platform would have to provide a non-standard linker of it's own. This is, > in fact, what happens with C++ on many platforms. If such a platform did not > allow the use of non-standard linkers, then a fully conforming implementation > of C would not be possible for that platform. > Actually, it is the linker which defines the requirements for the compiler. But the standard does not require a linker. All it requires is the externals be satisfied. That could, for instance, be done at run time by the program loader. No, no OS I know of does it this way. But it is within the limits of the standard. > ... >> The standard also doesn't say it has to be conforming "by default". > > People have pointed out, correctly, that most implementations don't conform in > their default mode, but no one has suggested that this violates any requirement > of the standard. That's just a straw man argument of your own invention. > I never said it had to conform by default. That's another case of your reading comprehension problem. Or trying to argue by putting words in my mouth. I'm not sure which. >> Just that it has to be conforming. > > Actually, it doesn't even say that. It only defines what being a conforming > implementation means. It nowhere imposes any requirement that anything, > anywhere in the universe, is required to match that definition. Something > advertised as conforming to the C standard should in fact conform, but that's > not because the standard says so, but because the false advertising laws say so. > To be a conforming implementation, by definition the compiler has to be conforming. More of your reading comprehension problem? Or are you once again arguing just to argue? >> The standard also doesn't say the compiler must have a means of >> compiling only (-c in gcc). But all compilers do. > > I've used compilers which could only compile - they had no capability of > calling the linker to link the program together. You had to do that explicitly > yourself. There was no need for a -c option on such a compiler, because it > corresponded to the default mode of that compiler. > Yes, I used some of those in the past, also. But that was because everything wouldn't fit on one diskette, and not everyone had hard disks (no one did when the PC first came out). >> I already agreed that you would have to specify which standard would be >> followed for a compiler which supports multiple standards. But you >> can't get by that, can you? Reading comprehension problems? > > I agree - but it's a reading comprehension issue on your part. The statement > you initially objected to was about the behavior of compilers in their default > mode. By definition, that's the mode in which no options are specified. In > particular, that means it's a mode in which no option is used to tell the > compiler to conform to a particular version of the standard. A compiler that > fully conforms to some version of the standard only when such an option is > selected does not qualify as a counter-example to Keith's claim, because it's > not in default mode. > Nope, no reading comprehension on my part. But you can't get past that, can you? You either have serious reading comprehension problems, or you are arguing just to argue. > There's other problems with your statement as well. This isn't just about > compilers that support multiple versions of the standard. There are compilers > that only conform to a single version of the standard. Even those compilers > don't conform to any version of the standard in default mode - they only > conform when you select the options that put them into conforming mode. > That's fine - and not against the standard at all. Now, let's see you name them. > Furthermore, you say that "you have to specify which standard would be > followed". That's not inherently true. It would have been entirely possible to > design a compiler that only fully conforms to C99 or C2011 when you select the > appropriate options, but which fully conforms to C90 if you select no options. > It's an odd fact, but apparently true, that there are no such compilers - at > least, no one monitoring this newsgroup (or comp.std.c) has nominated a > compiler as having that feature, without having the claim almost immediately > disproved. And it's precisely that odd fact that Keith was talking about, which you objected to. > Once again your reading comprehension problems show through. What I said was "when the compiler supports multiple standards, you have to specify which standard would be followed." And now you're saying you CAN have a compiler conform to a standard in default mode. Which one does that? All you're doing is showing what an idiot you are. Either you have serious reading comprehension problems, or you argue just to argue. Either way, you're showing you need serious help. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-09 16:21 +0000 |
| Message-ID | <o2elkn$p7$2@dont-email.me> |
| In reply to | #98544 |
My entry for the 2016 Selective Quotation of the Year contest: On 09/12/16 16:05, Jerry Stuckle wrote: > > Nope, no reading comprehension on my part. (Yes, he really did write that.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web