Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #61655 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2015-05-06 18:54 -0700 |
| Last post | 2015-05-18 16:07 -0400 |
| Articles | 20 on this page of 122 — 13 participants |
Back to article view | Back to comp.lang.c
A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 18:54 -0700
A Note on Readability asetofsymbols@gmail.com - 2015-05-06 23:08 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-07 07:34 +0100
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 12:22 -0700
Re: A Note on Readability raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:50 +0000
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:40 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-17 18:06 +0100
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:38 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 14:07 -0400
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 10:07 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-19 11:23 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-20 08:41 -0700
Re: A Note on Readability asetofsymbols@gmail.com - 2015-05-20 09:03 -0700
Re: A Note on Readability Les Cargill <lcargill99@comcast.com> - 2015-05-20 12:09 -0500
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 09:08 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-20 17:15 +0100
Re: A Note on Readability Les Cargill <lcargill99@comcast.com> - 2015-05-20 12:10 -0500
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 08:58 -0700
Re: A Note on Readability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 17:33 +0000
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-22 09:47 -0700
Re: A Note on Readability Les Cargill <lcargill99@comcast.com> - 2015-05-20 12:08 -0500
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-20 13:43 -0400
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-20 10:59 -0700
Re: A Note on Readability Les Cargill <lcargill99@comcast.com> - 2015-05-20 18:05 -0500
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-20 17:36 -0700
Re: A Note on Readability Les Cargill <lcargill99@comcast.com> - 2015-05-20 22:12 -0500
Re: A Note on Readability Philip Lantz <prl@canterey.us> - 2015-05-20 20:34 -0700
Re: A Note on Readability glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 04:39 +0000
Re: A Note on Readability Philip Lantz <prl@canterey.us> - 2015-05-21 17:41 -0700
Re: A Note on Readability gwowen <gwowen@gmail.com> - 2015-05-21 01:14 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 09:26 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-21 10:33 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-22 09:42 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-22 11:53 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-23 10:01 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-23 14:53 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 09:18 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-24 13:13 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:38 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-25 12:40 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 10:56 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-26 12:35 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-27 10:08 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-27 11:07 -0700
Re: A Note on Readability Robert Wessel <robertwessel2@yahoo.com> - 2015-05-27 20:17 -0500
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:56 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-25 13:05 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 09:58 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-26 18:16 +0100
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 10:55 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-26 12:11 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-26 12:01 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-27 09:58 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-27 18:11 +0100
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-28 12:11 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-28 12:55 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-29 10:08 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-06-01 18:54 +0100
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 11:29 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 09:06 -0700
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:42 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:20 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-12 11:24 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 08:48 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-07-13 12:38 -0400
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:34 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-07-13 14:43 -0400
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-13 12:18 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-07-13 15:27 -0400
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:45 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-14 09:05 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:41 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-14 10:26 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:59 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-07-14 12:25 -0400
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-13 13:46 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:33 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-13 11:17 -0700
Re: A Note on Readability Richard Damon <Richard@Damon-Family.org> - 2015-07-13 21:06 -0400
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-07-13 22:38 -0400
Re: A Note on Readability Richard Damon <Richard@Damon-Family.org> - 2015-07-15 08:19 -0400
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 09:10 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-07-13 11:00 -0700
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:11 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-27 10:57 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 09:51 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-24 13:36 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 10:00 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-25 13:05 -0700
Re: A Note on Readability Philip Lantz <prl@canterey.us> - 2015-05-24 16:43 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 09:57 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-24 13:37 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 10:14 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-25 13:11 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 10:26 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-26 18:38 +0100
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-26 12:24 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-27 10:06 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-27 11:05 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 10:38 -0700
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 07:01 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 09:58 -0700
Re: A Note on Readability Philip Lantz <prl@canterey.us> - 2015-05-25 00:45 -0700
Re: A Note on Readability Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 11:09 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 09:04 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-21 10:36 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-22 09:56 -0700
Re: A Note on Readability Robert Wessel <robertwessel2@yahoo.com> - 2015-05-22 12:16 -0500
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-22 14:14 -0400
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-23 09:49 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-22 11:55 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-22 11:58 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-20 10:26 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-18 11:08 -0700
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 10:09 -0700
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 20:40 +0100
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-17 14:34 -0400
Re: A Note on Readability David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:40 -0700
Re: A Note on Readability Keith Thompson <kst-u@mib.org> - 2015-05-18 11:18 -0700
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 14:33 -0400
Re: A Note on Readability Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 20:44 +0100
Re: A Note on Readability James Kuyper <jameskuyper@verizon.net> - 2015-05-18 16:07 -0400
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-26 10:56 -0700 |
| Message-ID | <e2261382-8b4b-4630-b2d4-a1caafc15a87@googlegroups.com> |
| In reply to | #62612 |
On Monday, May 25, 2015 at 12:41:01 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > The runtime library, specified in section 7 of the standard, is clearly > part of the "implementation". You seem to have been using it in a sense > that excludes the standard library. Did I misunderstand you? We are getting all twisted up. Regardless of what the standard says I mean an actual C (whatever version) compiler running on an actual computer and compiling an actual C source program into an actual object code. I think the standard, in fact, says the code must run on the same computer immediately after compilation - but I don't think that was what they intended so I ignore it . De minimus. I also ignore the question of how the object is realized - assembly or binary or what not. I don't see that what I (and I imagine the standard) say requires me to use the standrds library. K&R, for example, (first sentence in chapter 7) say "Input and output facilities are not part of the C language ... " It would be quite possible to write and run a C program with different i/o functions. > > I dunno about you but, like Hunpty-Dumpty, I am in charge of what I say - > > not the standard. My words are all meant as ordinary English words > > unless I sopecifically label them as technical or they only have > > technical meaning (eg "struct"). > > I ask you what you mean by "implementation", and you cite the definition > given in the standard. Then you make this statement about Humpty Dumpty > (which is usually used as an example of how *not* to communicate > clearly). Do you see a contradiction there? Don't you see the irony - who is acting like HD here? I give the standard no more authority than I give myself. To me the C language is what is described in a formal language like BNF. But I acknowledge that that is only the syntax of C. The semantics also matter but nothing more. In a sense though, the semantics are a comment on the syntax.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-26 12:35 -0700 |
| Message-ID | <87h9qzm8st.fsf@kst-u.example.com> |
| In reply to | #62653 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, May 25, 2015 at 12:41:01 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> The runtime library, specified in section 7 of the standard, is clearly
>> part of the "implementation". You seem to have been using it in a sense
>> that excludes the standard library. Did I misunderstand you?
>
> We are getting all twisted up. Regardless of what the standard says I
> mean an actual C (whatever version) compiler running on an actual
> computer and compiling an actual C source program into an actual
> object code. I think the standard, in fact, says the code must run
> on the same computer immediately after compilation - but I don't think
> that was what they intended so I ignore it . De minimus.
No, the standard does not say that the code must run on the same
computer. Where did you get that idea? A conforming compiler can
be a cross-compiler.
[...]
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-27 10:08 -0700 |
| Message-ID | <18bdb207-25aa-4a1d-a81a-524ad90dde21@googlegroups.com> |
| In reply to | #62662 |
On Tuesday, May 26, 2015 at 12:35:22 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Monday, May 25, 2015 at 12:41:01 PM UTC-7, Keith Thompson wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > >> The runtime library, specified in section 7 of the standard, is clearly > >> part of the "implementation". You seem to have been using it in a sense > >> that excludes the standard library. Did I misunderstand you? > > > > We are getting all twisted up. Regardless of what the standard says I > > mean an actual C (whatever version) compiler running on an actual > > computer and compiling an actual C source program into an actual > > object code. I think the standard, in fact, says the code must run > > on the same computer immediately after compilation - but I don't think > > that was what they intended so I ignore it . De minimus. > > No, the standard does not say that the code must run on the same > computer. Where did you get that idea? A conforming compiler can > be a cross-compiler. Did you read what I wrote? I suggested that the wording of the standard was flawed and could be interpreted in a way opposite to what they intended.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-27 11:07 -0700 |
| Message-ID | <87zj4plwr2.fsf@kst-u.example.com> |
| In reply to | #62679 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, May 26, 2015 at 12:35:22 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[SNIP]
>> > I think the standard, in fact, says the code must run on the same
>> > computer immediately after compilation - but I don't think that was
>> > what they intended so I ignore it . De minimus.
>>
>> No, the standard does not say that the code must run on the same
>> computer. Where did you get that idea? A conforming compiler can
>> be a cross-compiler.
>
> Did you read what I wrote?
Not carefully enough, it seems.
> I suggested that the wording of the standard was flawed and could be
> interpreted in a way opposite to what they intended.
If the standard implied that code must run on the same system
immediately after compilation, that would be a flaw in the standard.
Where exactly does it appear to say that? (And if you're pointing out
such a major flaw in the standard, *why didn't you cite it in the first
place*?)
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-27 20:17 -0500 |
| Message-ID | <fuqcmal4ethgm7eru5cvjfcb7q05tbost1@4ax.com> |
| In reply to | #62690 |
On Wed, 27 May 2015 11:07:45 -0700, Keith Thompson <kst-u@mib.org> wrote: >David Kleinecke <dkleinecke@gmail.com> writes: > >> On Tuesday, May 26, 2015 at 12:35:22 PM UTC-7, Keith Thompson wrote: >>> David Kleinecke <dkleinecke@gmail.com> writes: >[SNIP] >>> > I think the standard, in fact, says the code must run on the same >>> > computer immediately after compilation - but I don't think that was >>> > what they intended so I ignore it . De minimus. >>> >>> No, the standard does not say that the code must run on the same >>> computer. Where did you get that idea? A conforming compiler can >>> be a cross-compiler. >> >> Did you read what I wrote? > >Not carefully enough, it seems. > >> I suggested that the wording of the standard was flawed and could be >> interpreted in a way opposite to what they intended. > >If the standard implied that code must run on the same system >immediately after compilation, that would be a flaw in the standard. > >Where exactly does it appear to say that? (And if you're pointing out >such a major flaw in the standard, *why didn't you cite it in the first >place*?) In fact, the standard quite explicitly separates the two: "5. Environment An implementation translates C source files and executes C programs in two data-processing-system environments, which will be called the translation environment and the execution environment in this International Standard. Their characteristics define and constrain the results of executing conforming C programs constructed according to the syntactic and semantic rules for conforming implementations." (from C99)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-25 09:56 -0700 |
| Message-ID | <cc35358c-9abe-4b0c-b30d-f6c2660c52b7@googlegroups.com> |
| In reply to | #62543 |
On Sunday, May 24, 2015 at 1:13:29 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > The kind of thing that doesn't happen would be if an implementation > > (my sense) were to automatically include some information (I assume > > defines) at the start of every translation unit. > > It can and does happen. > > Several macro names are predefined by the compiler because the standard > requires them to be: > > __DATE__ > __FILE__ > __LINE__ > __STDC__ > __STDC_HOSTED__ > __STDC_VERSION__ > __TIME__ > > (This list is from N1570 (C11) 6.10.8.1; they're not all defined by > C90.) > > Compilers may and routinely do predefine other macros using reserved > identifiers. gcc, for example, predefines over 200 of them on > the system I'm using, all of them with names starting with "__". > They're all predefined by the compiler, independent of the library. > Run "gcc -E -dM" on any source file to see a list. > > There is no coherent sense of the word "implementation" for which your > statement is correct. C90 does know about pre-defined macros (4 of them) but makes no provision for additional implementation-defined macros. I see them used in preprocessor conditionals and have always assumed the compilers were being more permissive than the standard. But I classified them with pragmas rather than macros. Since the standard is silent I am unsure how these "pragmas" are implemented - but pre-defined macros would be possible - and I was wrong to say it never happens. Now - just how portable is implementation-dependent code? I have seen no abuse in actual code but I can imagine problems. If all the implementation-dependent code is in pre-processor conditionals that always have a reasonable default there will be no problem but I can imagine situations where no default is offered and vital code is never sent to the parser.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-25 13:05 -0700 |
| Message-ID | <87bnh8o234.fsf@kst-u.example.com> |
| In reply to | #62604 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> C90 does know about pre-defined macros (4 of them) but makes no
> provision for additional implementation-defined macros.
Yes, it does.
C90 6.8.8 lists the 5 (not 4) predefined macros that "shall be defined
by the implementation", and then says:
All predefined macro names shall begin with a leading underscore
followed by an uppercase letter or a second underscore.
IMNSHO that clearly implies that compilers are permitted to predefine
macros other than the 5 standard ones. If that were not the intent,
then that sentence would be meaningless. Do you have a different
interpretation?
[...]
> Now - just how portable is implementation-dependent code?
If it's written correctly, it's portable to the implementation(s) on
which it's dependent. (That seems so obvious that I suspect I've
misunderstood your question.)
> I have seen
> no abuse in actual code but I can imagine problems. If all the
> implementation-dependent code is in pre-processor conditionals that
> always have a reasonable default there will be no problem but I can
> imagine situations where no default is offered and vital code is never
> sent to the parser.
I'm not sure what you mean by "abuse", but you've seen the (mis)use
of reserved identifiers in GTK+.
A conforming compiler is permitted to predefine the identifier
_GeditTab as a macro. The GTK+ code would probably fail to compile
with such a compiler (depending on what _GeditTab expands to).
I'm not saying that this was a bad decision, but the behavior of
the code is not defined by the C standard, and the authors of GTK+
apparently are relying on the behavior of the C implementations being
used. They could have used unreserved identifiers instead -- and
a carefully chosen naming convention could probably have given them
the same benefits of (probably) avoiding collisions with user code.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-26 09:58 -0700 |
| Message-ID | <c50a33a2-0dc7-43c0-aec9-03db5aa1a5e5@googlegroups.com> |
| In reply to | #62613 |
On Monday, May 25, 2015 at 1:05:13 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > C90 does know about pre-defined macros (4 of them) but makes no > > provision for additional implementation-defined macros. > > Yes, it does. > > C90 6.8.8 lists the 5 (not 4) predefined macros that "shall be defined > by the implementation", and then says: > > All predefined macro names shall begin with a leading underscore > followed by an uppercase letter or a second underscore. > > IMNSHO that clearly implies that compilers are permitted to predefine > macros other than the 5 standard ones. If that were not the intent, > then that sentence would be meaningless. Do you have a different > interpretation? Yes. I read that differently. This is an extreme case of language lawyering. But I doubt that SCOTUS will interested in resolving it. However I admit that pre-defined macros would be good to have as a tool. I think you have stated your opinon that I could start my code with _X: and do whatever I want thereafter - because everything is now undefined. You really mean that? > [...] > > > Now - just how portable is implementation-dependent code? > > If it's written correctly, it's portable to the implementation(s) on > which it's dependent. (That seems so obvious that I suspect I've > misunderstood your question.) > > > I have seen > > no abuse in actual code but I can imagine problems. If all the > > implementation-dependent code is in pre-processor conditionals that > > always have a reasonable default there will be no problem but I can > > imagine situations where no default is offered and vital code is never > > sent to the parser. > > I'm not sure what you mean by "abuse", but you've seen the (mis)use > of reserved identifiers in GTK+. > > A conforming compiler is permitted to predefine the identifier > _GeditTab as a macro. The GTK+ code would probably fail to compile > with such a compiler (depending on what _GeditTab expands to). > > I'm not saying that this was a bad decision, but the behavior of > the code is not defined by the C standard, and the authors of GTK+ > apparently are relying on the behavior of the C implementations being > used. They could have used unreserved identifiers instead -- and > a carefully chosen naming convention could probably have given them > the same benefits of (probably) avoiding collisions with user code. > > -- > 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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-26 18:16 +0100 |
| Message-ID | <mk29n7$mrf$1@dont-email.me> |
| In reply to | #62645 |
On 26/05/15 17:58, David Kleinecke wrote: > On Monday, May 25, 2015 at 1:05:13 PM UTC-7, Keith Thompson wrote: <snip> >> >> All predefined macro names shall begin with a leading underscore >> followed by an uppercase letter or a second underscore. >> >> IMNSHO that clearly implies that compilers are permitted to predefine >> macros other than the 5 standard ones. If that were not the intent, >> then that sentence would be meaningless. Do you have a different >> interpretation? > > Yes. I read that differently. This is an extreme case of language > lawyering. But I doubt that SCOTUS will interested in resolving it. That is actually a very, very mild case of language lawyering. This newsgroup has carried a great many discussions far more involved than that one. > However I admit that pre-defined macros would be good to have as a tool. The point is that there has to be a namespace separation between the implementation and your code. If you tread on implementation namespace, you run the risk of a conflict either with your current implementation or on some implementation to which you later port the code. The namespace rules are not particularly onerous for the most part, and it's reasonably easy to avoid them without having to jump through too many hoops. > I think you have stated your opinon that I could start my code with > > _X: > > and do whatever I want thereafter - because everything is now undefined. > You really mean that? If your code doesn't conform to the C Standard, the C Standard imposes no requirements on the implementation. In other words, your compiler could generate any old junk instead of the executable image you wished it to generate, and you'd have no non-conformance claim against the vendor. In practice, the implementation will almost certainly do the best it can to honour your intent but, when you tread on implementation namespace, it ceases to become clear what your intent actually *is* (not to you - obviously *you* know what you want - but to the compiler). The cost of staying out of implementation namespace is trivially low. The cost of not doing so can be arbitrarily high. It's a no-brainer. <snip> -- 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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-26 10:55 -0700 |
| Message-ID | <21a4fbaa-6336-4f06-98fc-c36bbe652f63@googlegroups.com> |
| In reply to | #62648 |
On Tuesday, May 26, 2015 at 10:16:38 AM UTC-7, Richard Heathfield wrote: > On 26/05/15 17:58, David Kleinecke wrote: > > On Monday, May 25, 2015 at 1:05:13 PM UTC-7, Keith Thompson wrote: > <snip> > >> > >> All predefined macro names shall begin with a leading underscore > >> followed by an uppercase letter or a second underscore. > >> > >> IMNSHO that clearly implies that compilers are permitted to predefine > >> macros other than the 5 standard ones. If that were not the intent, > >> then that sentence would be meaningless. Do you have a different > >> interpretation? > > > > Yes. I read that differently. This is an extreme case of language > > lawyering. But I doubt that SCOTUS will interested in resolving it. > > That is actually a very, very mild case of language lawyering. This > newsgroup has carried a great many discussions far more involved than > that one. > > > However I admit that pre-defined macros would be good to have as a tool. > > The point is that there has to be a namespace separation between the > implementation and your code. If you tread on implementation namespace, > you run the risk of a conflict either with your current implementation > or on some implementation to which you later port the code. > > The namespace rules are not particularly onerous for the most part, and > it's reasonably easy to avoid them without having to jump through too > many hoops. > > > I think you have stated your opinon that I could start my code with > > > > _X: > > > > and do whatever I want thereafter - because everything is now undefined. > > You really mean that? > > If your code doesn't conform to the C Standard, the C Standard imposes > no requirements on the implementation. In other words, your compiler > could generate any old junk instead of the executable image you wished > it to generate, and you'd have no non-conformance claim against the > vendor. In practice, the implementation will almost certainly do the > best it can to honour your intent but, when you tread on implementation > namespace, it ceases to become clear what your intent actually *is* (not > to you - obviously *you* know what you want - but to the compiler). > > The cost of staying out of implementation namespace is trivially low. > The cost of not doing so can be arbitrarily high. It's a no-brainer. It's a nit to complain that reserved identfiers and namespaces are two different ideas. What you are calling implentation namespace, if I read you correctly, is the reserved identifiers. If you look at big collections of stuff like GTK+ you observe that everything has names that start with some module identifier. Like all the new things in gedit have names like "gedit_tab_ ..." or "GeditTab..." in module gedit-tab.h. All the reserved identifiers idea adds is to make the standard library (and its implementation friends) the anonymous module. Maybe a good idea but I think better made explicit. This whole question of how we handle identifier overlap seems to me to need a good overhaul.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-26 12:11 -0700 |
| Message-ID | <87pp5nm9vw.fsf@kst-u.example.com> |
| In reply to | #62652 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> If you look at big collections of stuff like GTK+ you observe that
> everything has names that start with some module identifier. Like all
> the new things in gedit have names like "gedit_tab_ ..." or "GeditTab..."
> in module gedit-tab.h. All the reserved identifiers idea adds is to
> make the standard library (and its implementation friends) the anonymous
> module. Maybe a good idea but I think better made explicit.
It *is* made explicit. We've been discussing the wording in the ISO C
standard that makes it explicit.
> This whole question of how we handle identifier overlap seems to me
> to need a good overhaul.
Personally, I'd like to see such an overhaul, probably using something
similar to C++ user-defined namespaces, but it's not likely to happen
any time soon. Meanwhile, we work with the rules given by the standard,
which IMHO are quite clear.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-26 12:01 -0700 |
| Message-ID | <87twuzmaca.fsf@kst-u.example.com> |
| In reply to | #62645 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, May 25, 2015 at 1:05:13 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > C90 does know about pre-defined macros (4 of them) but makes no
>> > provision for additional implementation-defined macros.
>>
>> Yes, it does.
>>
>> C90 6.8.8 lists the 5 (not 4) predefined macros that "shall be defined
>> by the implementation", and then says:
>>
>> All predefined macro names shall begin with a leading underscore
>> followed by an uppercase letter or a second underscore.
>>
>> IMNSHO that clearly implies that compilers are permitted to predefine
>> macros other than the 5 standard ones. If that were not the intent,
>> then that sentence would be meaningless. Do you have a different
>> interpretation?
>
> Yes. I read that differently. This is an extreme case of language
> lawyering. But I doubt that SCOTUS will interested in resolving it.
I don't see it as language lawyering, just a straightforward reading of
what the standard says.
*What* is your interpretation of that clause? (I thought that was
implicit in my question.) Do you believe that the standard imposes
a specific requirement on predefined macro names and also does
not allow predefined macro names other than the ones in the list?
Please clarify.
> However I admit that pre-defined macros would be good to have as a tool.
>
> I think you have stated your opinon that I could start my code with
>
> _X:
>
> and do whatever I want thereafter - because everything is now undefined.
> You really mean that?
I'm going to assume that you meant to have
_X:
in a place where a label is syntactically valid.
I really mean that if your program contains
_X:
in such a context, then its behavior is undefined. That doesn't mean
you can do anything you want thereafter; you don't necessarily have
any control over your program's behavior. _X could be a predefined
macro or an implementation-defined keyword, for example.
BTW, when you're posting a followup, please trim any quoted material
that you're not replying to, and that's not necessary to understanding
your followup. In particular, please don't quote signatures.
[SNIP]
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-27 09:58 -0700 |
| Message-ID | <4175e1ca-0317-4f15-bcb8-0c0f8ac1cc9a@googlegroups.com> |
| In reply to | #62659 |
On Tuesday, May 26, 2015 at 12:02:11 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Monday, May 25, 2015 at 1:05:13 PM UTC-7, Keith Thompson wrote: >> C90 6.8.8 lists the 5 (not 4) predefined macros that "shall be defined >> by the implementation", and then says: >> >> All predefined macro names shall begin with a leading underscore >> followed by an uppercase letter or a second underscore. >> > >> IMNSHO that clearly implies that compilers are permitted to predefine > >> macros other than the 5 standard ones. If that were not the intent, > >> then that sentence would be meaningless. Do you have a different > >> interpretation? > > > > Yes. I read that differently. This is an extreme case of language > > lawyering. But I doubt that SCOTUS will interested in resolving it. > > I don't see it as language lawyering, just a straightforward reading of > what the standard says. > > *What* is your interpretation of that clause? (I thought that was > implicit in my question.) Do you believe that the standard imposes > a specific requirement on predefined macro names and also does > not allow predefined macro names other than the ones in the list? > Please clarify. Let the lawyering begin. The standard does not explicitly address the question of implementor defined pre-defined macros (or I haven't found such a passage yet). So we have to guess what it should have said. You take the position that it implicitly allows them. I take the position that if it had intended to allow them it would have said so. I see no way to resolve this dilemma. PS: This question is quite independent of the question about the shape of the names of these macros.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-27 18:11 +0100 |
| Message-ID | <mk4tpi$u87$1@dont-email.me> |
| In reply to | #62677 |
On 27/05/15 17:58, David Kleinecke wrote: <snip> > Let the lawyering begin. > > The standard does not explicitly address the question of implementor > defined pre-defined macros (or I haven't found such a passage yet). > So we have to guess what it should have said. No need to guess. 4.6: "A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program." A strictly conforming program must not define any identifier that begins with an underscore and an upper case letter, or with two consecutive underscores. (See 7.1.3 Reserved Identifiers.) So an implementation is free to provide pre-defined macros that begin with __ or _[A-Z], because such macros cannot possibly alter the behaviour of a strictly conforming program. > You take the position that it implicitly allows them. I take the position > that if it had intended to allow them it would have said so. It said so. It just used different words to the ones you were expecting. > > I see no way to resolve this dilemma. Read the Standard with an open mind, and you'll see it. > PS: This question is quite independent of the question about the shape > of the names of these macros. No, it isn't. Implementations are only free to provide macros because there is a way to define them that doesn't affect strictly conforming programs, and that is only possible because strictly conforming programs must follow the rules for reserved identifiers. -- 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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-28 12:11 -0700 |
| Message-ID | <49850ea6-3141-4015-9e8c-b8b9e92a7728@googlegroups.com> |
| In reply to | #62680 |
On Wednesday, May 27, 2015 at 10:11:29 AM UTC-7, Richard Heathfield wrote: > On 27/05/15 17:58, David Kleinecke wrote: > > <snip> > > > Let the lawyering begin. > > > > The standard does not explicitly address the question of implementor > > defined pre-defined macros (or I haven't found such a passage yet). > > So we have to guess what it should have said. > > No need to guess. 4.6: "A conforming implementation may have extensions > (including additional library functions), provided they do not alter the > behavior of any strictly conforming program." > > A strictly conforming program must not define any identifier that begins > with an underscore and an upper case letter, or with two consecutive > underscores. (See 7.1.3 Reserved Identifiers.) > > So an implementation is free to provide pre-defined macros that begin > with __ or _[A-Z], because such macros cannot possibly alter the > behaviour of a strictly conforming program. > > > You take the position that it implicitly allows them. I take the position > > that if it had intended to allow them it would have said so. > > It said so. It just used different words to the ones you were expecting. > > > > > I see no way to resolve this dilemma. > > Read the Standard with an open mind, and you'll see it. > > > PS: This question is quite independent of the question about the shape > > of the names of these macros. > > No, it isn't. Implementations are only free to provide macros because > there is a way to define them that doesn't affect strictly conforming > programs, and that is only possible because strictly conforming programs > must follow the rules for reserved identifiers. Excellent lawyering. The standard does not define extensions (other than additional library funtions) so I think 4.6 is moot. But, anyway that's not all the C90 standard says (all of clause 4): <quote> A strictly conforming program shall use only those features of the language and library defined in this International Standard. It shall not produce output ependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit. The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program in which use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>. A conforming implementation may have extension (including additional library functions) provided they do not alter the behavior of any strictly conforming program. [ftn: This implies that a conforming implementation reserves no identifiers other than those explicitly reserved in this Internatinal Standard.] A conforming program is one that is acceptable to a conforming implementation. [ftn: Strictly conforming programs are intended to be maximally portable among conforming implementations. Conforming programs may depend upon nonportable features of a conforming implementation.] An implementation shall be accompanied by a document that defines all implementation defined characteristics and all extensions. </quote> I like that last sentence. I think (because "shall" has not been explicitly defined) that every implementation must be accompanied by such a document. I've never seen one. Do any exist? Assuming no such documents exist I think I can easily not take the standard seriously as I have been. The footnote to the second paragraph requires only "explicity" reserved identifiers to used in a conforming implementation. In C90, using the 7.1.3 definition there are exactly three explicitly reserved identifiers - "_IOFBF", "_IOLBF" and "_IONBF". But that depends on how one understands "explicitly". 7.1.3 defines many more reserved identifiers but, as I use the word, not "explicitly". Looking at 7.1.3 I see several implict references to 7.13 "Future library directions". I think this is relevant to any understanding of what "reserved" means but I don't see how it all fits together.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-28 12:55 -0700 |
| Message-ID | <87egm0lbnw.fsf@kst-u.example.com> |
| In reply to | #62740 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 27, 2015 at 10:11:29 AM UTC-7, Richard Heathfield wrote:
>> On 27/05/15 17:58, David Kleinecke wrote:
>>
>> <snip>
>>
>> > Let the lawyering begin.
>> >
>> > The standard does not explicitly address the question of implementor
>> > defined pre-defined macros (or I haven't found such a passage yet).
>> > So we have to guess what it should have said.
>>
>> No need to guess. 4.6: "A conforming implementation may have extensions
>> (including additional library functions), provided they do not alter the
>> behavior of any strictly conforming program."
>>
>> A strictly conforming program must not define any identifier that begins
>> with an underscore and an upper case letter, or with two consecutive
>> underscores. (See 7.1.3 Reserved Identifiers.)
>>
>> So an implementation is free to provide pre-defined macros that begin
>> with __ or _[A-Z], because such macros cannot possibly alter the
>> behaviour of a strictly conforming program.
>>
>> > You take the position that it implicitly allows them. I take the position
>> > that if it had intended to allow them it would have said so.
>>
>> It said so. It just used different words to the ones you were expecting.
>>
>> >
>> > I see no way to resolve this dilemma.
>>
>> Read the Standard with an open mind, and you'll see it.
>>
>> > PS: This question is quite independent of the question about the shape
>> > of the names of these macros.
>>
>> No, it isn't. Implementations are only free to provide macros because
>> there is a way to define them that doesn't affect strictly conforming
>> programs, and that is only possible because strictly conforming programs
>> must follow the rules for reserved identifiers.
>
> Excellent lawyering.
>
> The standard does not define extensions (other than additional library
> funtions) so I think 4.6 is moot.
I think the meaning of the word "extensions" is clear enough: features
not specified by the standard. No, 4.6 is not moot. Just one example:
gcc implements binary integer constants like 0b11001001; that's clearly
an extension within the meaning of 4.6. gcc's statement expressions are
nother example.
> But, anyway that's not all the C90 standard says (all of clause 4):
[snip]
> An implementation shall be accompanied by a document that defines
> all implementation defined characteristics and all extensions.
> </quote>
>
> I like that last sentence. I think (because "shall" has not been
> explicitly defined) that every implementation must be accompanied
> by such a document. I've never seen one. Do any exist?
In C90, the first paragraph of section 3 discusses the meanings of
"shall" and "shall not". The definition of "undefined behavior" in 3.16
discusses it further.
Yes, such documents do exist, as they must for any conforming C
implementation. For example, it's section 4 of the gcc manual, which
includes references to other documentation.
> Assuming no such documents exist I think I can easily not take the
> standard seriously as I have been.
Your assumption is incorrect. You conclusion is correct; you are not
required to take the standard seriously at all. You're free to ignore
it completely if you like.
And yet you continue to discuss it here.
> The footnote to the second paragraph requires only "explicity"
> reserved identifiers to used in a conforming implementation.
> In C90, using the 7.1.3 definition there are exactly three explicitly
> reserved identifiers - "_IOFBF", "_IOLBF" and "_IONBF". But that
> depends on how one understands "explicitly". 7.1.3 defines many more
> reserved identifiers but, as I use the word, not "explicitly".
>
> Looking at 7.1.3 I see several implict references to 7.13 "Future
> library directions". I think this is relevant to any understanding
> of what "reserved" means but I don't see how it all fits together.
The standard doesn't have to list every reserved identifier individually
for them to be "explicitly reserved". All identifiers starting with two
underscores, or with an underscore and an uppercase letter, are reserved
(as are some others). The standard is quite explicit about that.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-29 10:08 -0700 |
| Message-ID | <8cd24f16-fac7-4a05-81c9-1ac8cfecb42a@googlegroups.com> |
| In reply to | #62745 |
On Thursday, May 28, 2015 at 12:55:44 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Wednesday, May 27, 2015 at 10:11:29 AM UTC-7, Richard Heathfield wrote: > >> On 27/05/15 17:58, David Kleinecke wrote: > >> > >> <snip> > >> > >> > Let the lawyering begin. > >> > > >> > The standard does not explicitly address the question of implementor > >> > defined pre-defined macros (or I haven't found such a passage yet). > >> > So we have to guess what it should have said. > >> > >> No need to guess. 4.6: "A conforming implementation may have extensions > >> (including additional library functions), provided they do not alter the > >> behavior of any strictly conforming program." > >> > >> A strictly conforming program must not define any identifier that begins > >> with an underscore and an upper case letter, or with two consecutive > >> underscores. (See 7.1.3 Reserved Identifiers.) > >> > >> So an implementation is free to provide pre-defined macros that begin > >> with __ or _[A-Z], because such macros cannot possibly alter the > >> behaviour of a strictly conforming program. > >> > >> > You take the position that it implicitly allows them. I take the position > >> > that if it had intended to allow them it would have said so. > >> > >> It said so. It just used different words to the ones you were expecting. > >> > >> > > >> > I see no way to resolve this dilemma. > >> > >> Read the Standard with an open mind, and you'll see it. > >> > >> > PS: This question is quite independent of the question about the shape > >> > of the names of these macros. > >> > >> No, it isn't. Implementations are only free to provide macros because > >> there is a way to define them that doesn't affect strictly conforming > >> programs, and that is only possible because strictly conforming programs > >> must follow the rules for reserved identifiers. > > > > Excellent lawyering. > > > > The standard does not define extensions (other than additional library > > funtions) so I think 4.6 is moot. > > I think the meaning of the word "extensions" is clear enough: features > not specified by the standard. No, 4.6 is not moot. Just one example: > gcc implements binary integer constants like 0b11001001; that's clearly > an extension within the meaning of 4.6. gcc's statement expressions are > nother example. > > > But, anyway that's not all the C90 standard says (all of clause 4): > [snip] > > An implementation shall be accompanied by a document that defines > > all implementation defined characteristics and all extensions. > > </quote> > > > > I like that last sentence. I think (because "shall" has not been > > explicitly defined) that every implementation must be accompanied > > by such a document. I've never seen one. Do any exist? > > In C90, the first paragraph of section 3 discusses the meanings of > "shall" and "shall not". The definition of "undefined behavior" in 3.16 > discusses it further. > > Yes, such documents do exist, as they must for any conforming C > implementation. For example, it's section 4 of the gcc manual, which > includes references to other documentation. > > > Assuming no such documents exist I think I can easily not take the > > standard seriously as I have been. > > Your assumption is incorrect. You conclusion is correct; you are not > required to take the standard seriously at all. You're free to ignore > it completely if you like. > > And yet you continue to discuss it here. > > > The footnote to the second paragraph requires only "explicity" > > reserved identifiers to used in a conforming implementation. > > In C90, using the 7.1.3 definition there are exactly three explicitly > > reserved identifiers - "_IOFBF", "_IOLBF" and "_IONBF". But that > > depends on how one understands "explicitly". 7.1.3 defines many more > > reserved identifiers but, as I use the word, not "explicitly". > > > > Looking at 7.1.3 I see several implict references to 7.13 "Future > > library directions". I think this is relevant to any understanding > > of what "reserved" means but I don't see how it all fits together. > > The standard doesn't have to list every reserved identifier individually > for them to be "explicitly reserved". All identifiers starting with two > underscores, or with an underscore and an uppercase letter, are reserved > (as are some others). The standard is quite explicit about that. This has gone on long enough. I'm not going to reply. However, expect more posts on various aspects of what I call core C.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-01 18:54 +0100 |
| Message-ID | <mki664$r53$2@dont-email.me> |
| In reply to | #62745 |
On 28/05/15 20:55, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: <snip> >> But, anyway that's not all the C90 standard says (all of clause 4): > [snip] >> An implementation shall be accompanied by a document that defines >> all implementation defined characteristics and all extensions. >> </quote> >> >> I like that last sentence. I think (because "shall" has not been >> explicitly defined) that every implementation must be accompanied >> by such a document. I've never seen one. Do any exist? > > In C90, the first paragraph of section 3 discusses the meanings of > "shall" and "shall not". The definition of "undefined behavior" in 3.16 > discusses it further. > > Yes, such documents do exist, as they must for any conforming C > implementation. For example, it's section 4 of the gcc manual, which > includes references to other documentation. I've never bothered to search for the gcc document, but of course I take your word for it. I *have* had occasion to read the Borland and Microsoft conformance documentation, so I can attest to their existence. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 11:29 -0700 |
| Message-ID | <kfnlhen50j4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62680 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 27/05/15 17:58, David Kleinecke wrote: > > <snip> > >> Let the lawyering begin. >> >> The standard does not explicitly address the question of implementor >> defined pre-defined macros (or I haven't found such a passage yet). >> So we have to guess what it should have said. > > No need to guess. 4.6: "A conforming implementation may have > extensions (including additional library functions), provided they > do not alter the behavior of any strictly conforming program." > [snip elaboration] Actually I think the rule about extensions doesn't matter. An implementation is free to define any reserved identifier, more specifically any identifier reserved for any use, without having to document it as an extension. They could also be documented as extensions, but the Standard does not require this; they are reserved for use by the implementation, which means (reasonably enough) that the implementation may use them as it sees fit. The phrasing in the Standard is a little vague about whether this is allowed in the absence of any header being included, but looking carefully at the various passages concerned it is clear that that is the intent.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-11 09:06 -0700 |
| Message-ID | <3db40dfc-407c-4229-9c61-aac75246cb7e@googlegroups.com> |
| In reply to | #65167 |
On Friday, July 10, 2015 at 11:29:51 AM UTC-7, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > > > On 27/05/15 17:58, David Kleinecke wrote: > > > > <snip> > > > >> Let the lawyering begin. > >> > >> The standard does not explicitly address the question of implementor > >> defined pre-defined macros (or I haven't found such a passage yet). > >> So we have to guess what it should have said. > > > > No need to guess. 4.6: "A conforming implementation may have > > extensions (including additional library functions), provided they > > do not alter the behavior of any strictly conforming program." > > [snip elaboration] > > Actually I think the rule about extensions doesn't matter. An > implementation is free to define any reserved identifier, more > specifically any identifier reserved for any use, without having > to document it as an extension. They could also be documented as > extensions, but the Standard does not require this; they are > reserved for use by the implementation, which means (reasonably > enough) that the implementation may use them as it sees fit. > > The phrasing in the Standard is a little vague about whether this > is allowed in the absence of any header being included, but > looking carefully at the various passages concerned it is clear > that that is the intent. Doesn't look clear to me. Looks vague. But I can see what common practice is. I think things like this ought to be documented - but I seem to be in the minority.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web