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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 13:42 -0700 |
| Message-ID | <kfny4imv32v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65301 |
David Kleinecke <dkleinecke@gmail.com> writes: > 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. Did you look carefully through all the different paragraphs concerned with the question? Can you tell me which ones you looked at?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-12 09:20 -0700 |
| Message-ID | <dd0b8b64-04ae-4804-8c95-bfdcb34a26ad@googlegroups.com> |
| In reply to | #65335 |
On Saturday, July 11, 2015 at 1:42:23 PM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > 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. > > Did you look carefully through all the different paragraphs > concerned with the question? Can you tell me which ones > you looked at? It's been too long and I can't tell you exactly where I looked. I imagine I looked everywhere. Remember I am disucssing the C90 standard and there is no section 4.6 in the C90 standard. I have no problems with the quoted 4.6 but I don't think it answers my original complaint. My original complaint is that the standard makes no provision for pre-defined material. I may not have made it clear that by pre-defined I mean things that function like part of the source code but are prepened to it at translation time. I have forgotten what the original example was. These things function like #include lines which are automatically written at the top of every translation unit. I think that if they exist at all they should be overt.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-12 11:24 -0700 |
| Message-ID | <lny4ilmdyy.fsf@kst-u.example.com> |
| In reply to | #65415 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> >> Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
>> >>> 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."
[...]
> Remember I am disucssing the C90 standard and there is no section
> 4.6 in the C90 standard. I have no problems with the quoted 4.6 but
> I don't think it answers my original complaint.
[...]
It's actually 4p6 (section 4, paragraph 6), not 4.6.
In the C11 standard, section 4 paragraph 6 says, in part:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
In the C90 standard, section 4 paragraph 2 says, in part:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
--
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-07-13 08:48 -0700 |
| Message-ID | <51b626e2-ffe7-45ad-949a-398cf5ab45cd@googlegroups.com> |
| In reply to | #65435 |
On Sunday, July 12, 2015 at 11:24:15 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> >> >> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
> >> >>> 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."
>
> [...]
>
> > Remember I am disucssing the C90 standard and there is no section
> > 4.6 in the C90 standard. I have no problems with the quoted 4.6 but
> > I don't think it answers my original complaint.
>
> [...]
>
> It's actually 4p6 (section 4, paragraph 6), not 4.6.
>
> In the C11 standard, section 4 paragraph 6 says, in part:
>
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any strictly conforming program.
>
> In the C90 standard, section 4 paragraph 2 says, in part:
>
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any strictly conforming program.
But it does say what an extension is - apart from an enlarged library.
I said I thought that that meant, in complier terms, that any point
where the parse fails could be given meaning (implementation-defined,
of course). But there doesn't seem to be agreement that that is what
the standard intended.
To illustrate what I meant consider the keyword "if". It must be
followed by "(". If I added the option that it could be followed by,
say, '[' and gave the construct some meaning that would be an
acceptable extension.
But my attempt to describe extensions is restrictive. Could I perhaps
define more keywords? For example
until (...) {...}
with meaning "while not".
I think any of things would be an acceptable extension because any
correct strictly conforming program would not be impacted.
Are C99, C11, etc. extensions of C90?
"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 12:38 -0400 |
| Message-ID | <55A3E9A3.7030602@verizon.net> |
| In reply to | #65489 |
On 07/13/2015 11:48 AM, David Kleinecke wrote:
> On Sunday, July 12, 2015 at 11:24:15 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
...
>>> Remember I am disucssing the C90 standard and there is no section
>>> 4.6 in the C90 standard. I have no problems with the quoted 4.6 but
>>> I don't think it answers my original complaint.
>>
>> [...]
>>
>> It's actually 4p6 (section 4, paragraph 6), not 4.6.
>>
>> In the C11 standard, section 4 paragraph 6 says, in part:
>>
>> A conforming implementation may have extensions (including
>> additional library functions), provided they do not alter the
>> behavior of any strictly conforming program.
>>
>> In the C90 standard, section 4 paragraph 2 says, in part:
>>
>> A conforming implementation may have extensions (including
>> additional library functions), provided they do not alter the
>> behavior of any strictly conforming program.
>
> But it does say what an extension is - apart from an enlarged library.
>
> I said I thought that that meant, in complier terms, that any point
> where the parse fails could be given meaning (implementation-defined,
> of course). But there doesn't seem to be agreement that that is what
> the standard intended.
It's also not what the standard says. If the parse fails, you have a
syntax error, and the program is not strictly conforming, so a
conforming extension is allowed to to alter the behavior of such a
program. However, having a parse failure is not the only way that an
extension can change the behavior - anything that prevents a program
from being strictly conforming could also be the basis for a conforming
extension. Other possibilities:
1. constraint violation
2. code with undefined behavior
3. code with unspecified behavior
4. code with implementation-defined behavior
5. code which exceeds any of the minimum implementation limits.
The third case is somewhat restrictive: the only kind of extension you
can provide that way is one that involves making a specific choice among
the possibilities allowed by the standard. The fourth one is even more
restricted - you must document the choice, and your compiler must
implement that choice. The other three cases all give you pretty much
unlimited freedom to do whatever you want.
> To illustrate what I meant consider the keyword "if". It must be
> followed by "(". If I added the option that it could be followed by,
> say, '[' and gave the construct some meaning that would be an
> acceptable extension.
>
> But my attempt to describe extensions is restrictive. Could I perhaps
> define more keywords? For example
> until (...) {...}
> with meaning "while not".
'until' is a name reserved to the users for all purposes. Therefore, a
conforming implementation of C can't treat it as a keyword if it occurs
in a strictly conforming program. However, if you use a construct with
undefined behavior to turn on recognition of 'until' as a keyword, that
would be allowed. You could also make recognition of 'until' as a
keyword be controlled by a #pragma.
> I think any of things would be an acceptable extension because any
> correct strictly conforming program would not be impacted.
Recognizing something as a keyword prevents it from being recognized as
an identifier during translation phase 7. Any strictly conforming
program that used 'until' as the name of an object, a function, a label,
a struct/union/enumeration tag or member name would parse as a syntax
error if your compiler recognizes it as a keyword instead.
> Are C99, C11, etc. extensions of C90?
They are C90 extensions, but they are not conforming extensions of C90.
Both of them changed the behavior of programs that have strictly
conforming behavior under C90.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-13 10:34 -0700 |
| Message-ID | <e4f73fe3-8173-4570-92c0-b4b6ca351e57@googlegroups.com> |
| In reply to | #65494 |
On Monday, July 13, 2015 at 9:39:11 AM UTC-7, James Kuyper wrote:
> On 07/13/2015 11:48 AM, David Kleinecke wrote:
> > On Sunday, July 12, 2015 at 11:24:15 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> ...
> >>> Remember I am disucssing the C90 standard and there is no section
> >>> 4.6 in the C90 standard. I have no problems with the quoted 4.6 but
> >>> I don't think it answers my original complaint.
> >>
> >> [...]
> >>
> >> It's actually 4p6 (section 4, paragraph 6), not 4.6.
> >>
> >> In the C11 standard, section 4 paragraph 6 says, in part:
> >>
> >> A conforming implementation may have extensions (including
> >> additional library functions), provided they do not alter the
> >> behavior of any strictly conforming program.
> >>
> >> In the C90 standard, section 4 paragraph 2 says, in part:
> >>
> >> A conforming implementation may have extensions (including
> >> additional library functions), provided they do not alter the
> >> behavior of any strictly conforming program.
> >
> > But it does say what an extension is - apart from an enlarged library.
> >
> > I said I thought that that meant, in complier terms, that any point
> > where the parse fails could be given meaning (implementation-defined,
> > of course). But there doesn't seem to be agreement that that is what
> > the standard intended.
>
> It's also not what the standard says. If the parse fails, you have a
> syntax error, and the program is not strictly conforming, so a
> conforming extension is allowed to to alter the behavior of such a
> program. However, having a parse failure is not the only way that an
> extension can change the behavior - anything that prevents a program
> from being strictly conforming could also be the basis for a conforming
> extension. Other possibilities:
> 1. constraint violation
> 2. code with undefined behavior
> 3. code with unspecified behavior
> 4. code with implementation-defined behavior
> 5. code which exceeds any of the minimum implementation limits.
>
> The third case is somewhat restrictive: the only kind of extension you
> can provide that way is one that involves making a specific choice among
> the possibilities allowed by the standard. The fourth one is even more
> restricted - you must document the choice, and your compiler must
> implement that choice. The other three cases all give you pretty much
> unlimited freedom to do whatever you want.
>
> > To illustrate what I meant consider the keyword "if". It must be
> > followed by "(". If I added the option that it could be followed by,
> > say, '[' and gave the construct some meaning that would be an
> > acceptable extension.
> >
> > But my attempt to describe extensions is restrictive. Could I perhaps
> > define more keywords? For example
> > until (...) {...}
> > with meaning "while not".
>
> 'until' is a name reserved to the users for all purposes. Therefore, a
> conforming implementation of C can't treat it as a keyword if it occurs
> in a strictly conforming program. However, if you use a construct with
> undefined behavior to turn on recognition of 'until' as a keyword, that
> would be allowed. You could also make recognition of 'until' as a
> keyword be controlled by a #pragma.
>
> > I think any of things would be an acceptable extension because any
> > correct strictly conforming program would not be impacted.
>
> Recognizing something as a keyword prevents it from being recognized as
> an identifier during translation phase 7. Any strictly conforming
> program that used 'until' as the name of an object, a function, a label,
> a struct/union/enumeration tag or member name would parse as a syntax
> error if your compiler recognizes it as a keyword instead.
>
> > Are C99, C11, etc. extensions of C90?
>
> They are C90 extensions, but they are not conforming extensions of C90.
> Both of them changed the behavior of programs that have strictly
> conforming behavior under C90.
I see why I must not invent new keywords. No matter - there are plenty
already. Perhaps I could invent "3until" because that's not going to
appear in a strictlty conforming program - not even as "3" plus "until".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 14:43 -0400 |
| Message-ID | <55A406BC.1010203@verizon.net> |
| In reply to | #65500 |
On 07/13/2015 01:34 PM, David Kleinecke wrote:
> On Monday, July 13, 2015 at 9:39:11 AM UTC-7, James Kuyper wrote:
>> On 07/13/2015 11:48 AM, David Kleinecke wrote:
...
>>> But my attempt to describe extensions is restrictive. Could I perhaps
>>> define more keywords? For example
>>> until (...) {...}
>>> with meaning "while not".
>>
>> 'until' is a name reserved to the users for all purposes. Therefore, a
>> conforming implementation of C can't treat it as a keyword if it occurs
>> in a strictly conforming program. However, if you use a construct with
>> undefined behavior to turn on recognition of 'until' as a keyword, that
>> would be allowed. You could also make recognition of 'until' as a
>> keyword be controlled by a #pragma.
>>
>>> I think any of things would be an acceptable extension because any
>>> correct strictly conforming program would not be impacted.
>>
>> Recognizing something as a keyword prevents it from being recognized as
>> an identifier during translation phase 7. Any strictly conforming
>> program that used 'until' as the name of an object, a function, a label,
>> a struct/union/enumeration tag or member name would parse as a syntax
>> error if your compiler recognizes it as a keyword instead.
...
> I see why I must not invent new keywords. No matter - there are plenty
> already. Perhaps I could invent "3until" because that's not going to
> appear in a strictlty conforming program - not even as "3" plus "until".
That's ugly, and you have better options. However, before I go into
those other options, there's also another issue that's more important
than "that's ugly".
During translation phase 3, "3until" must be parsed as a preprocessing
number ('3') followed by an identifier - keywords are not relevant until
phase 7. During translation phase 7, "Each preprocessing token is
converted into a token." - there's no merging and no splitting.
Therefore, it must be parsed as the integer constant 3 followed by the
identifier "until". Now, you can specify the grammar for your extension
as saying that this combination of tokens has the effect that you
desire. However, by the general rules specified for parsing C code, if
"3until" has that effect, then so should "3 until", "3\tuntil" and
"3\nuntil". That's because white space separating tokens gets dropped
during translation phase 7. I don't think you would want it to work that
way.
Either way, as you say, it's a syntax error, and thus a legitimate basis
for triggering a conforming extension - and perhaps that extension could
involve parsing this particular construct differently. However, if I
were trying to make this work, I'd be worried that modifying the parsing
rules to allow 3until to be parsed as a single keyword, might result in
something else breaking, possibly in ways that would affect even
strictly conforming code. I haven't come up with any examples yet, so
count that as a vague uneasiness rather than a solid objection.
You don't have to mess with the parsing rules. The far more conventional
way to handle this issue is to use the name space reserved to the
implementation. That's precisely the reason that name space was
reserved. You can use _Until or __until, and there's no parsing problems
and it is still a construct that can't appear in a strictly conforming
program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-13 12:18 -0700 |
| Message-ID | <lnzj2zlvc9.fsf@kst-u.example.com> |
| In reply to | #65507 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 07/13/2015 01:34 PM, David Kleinecke wrote:
[...]
>> I see why I must not invent new keywords. No matter - there are plenty
>> already. Perhaps I could invent "3until" because that's not going to
>> appear in a strictlty conforming program - not even as "3" plus "until".
>
> That's ugly, and you have better options. However, before I go into
> those other options, there's also another issue that's more important
> than "that's ugly".
>
> During translation phase 3, "3until" must be parsed as a preprocessing
> number ('3') followed by an identifier - keywords are not relevant until
> phase 7. During translation phase 7, "Each preprocessing token is
> converted into a token." - there's no merging and no splitting.
Right.
> Therefore, it must be parsed as the integer constant 3 followed by the
> identifier "until".
Hmm? As you just wrote, there's no splitting. The preprocessor number
3until is converted to a single token. Since 3until is not a
syntactically valid token, it's a syntax error. It's not equivalent to
the token 3 followed by the token until.
gcc complains:
error: invalid suffix "until" on integer constant
> You don't have to mess with the parsing rules. The far more conventional
> way to handle this issue is to use the name space reserved to the
> implementation. That's precisely the reason that name space was
> reserved. You can use _Until or __until, and there's no parsing problems
> and it is still a construct that can't appear in a strictly conforming
> program.
Right. The _Until form has become the conventional way to add new
keywords; both C99 and C11 have added keywords with that general form,
often along with a new header that defines a more convenient macro
(see _Bool, <stdbool.h>, bool).
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 15:27 -0400 |
| Message-ID | <55A41122.4010600@verizon.net> |
| In reply to | #65512 |
On 07/13/2015 03:18 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 07/13/2015 01:34 PM, David Kleinecke wrote:
> [...]
>>> I see why I must not invent new keywords. No matter - there are plenty
>>> already. Perhaps I could invent "3until" because that's not going to
>>> appear in a strictlty conforming program - not even as "3" plus "until".
>>
>> That's ugly, and you have better options. However, before I go into
>> those other options, there's also another issue that's more important
>> than "that's ugly".
>>
>> During translation phase 3, "3until" must be parsed as a preprocessing
>> number ('3') followed by an identifier - keywords are not relevant until
>> phase 7. During translation phase 7, "Each preprocessing token is
>> converted into a token." - there's no merging and no splitting.
>
> Right.
>
>> Therefore, it must be parsed as the integer constant 3 followed by the
>> identifier "until".
>
> Hmm? As you just wrote, there's no splitting. The preprocessor number
> 3until is converted to a single token. Since 3until is not a
> syntactically valid token, it's a syntax error. It's not equivalent to
> the token 3 followed by the token until.
Sorry, you're correct. I reviewed the grammar rules for pre-processing
numbers, before writing that, and for some reasons my eyes just skipped
right over the "pp-number identifier-nondigit" production. If I'd
thought about it just a little bit, I would have realized that, with
that misunderstanding, neither 3U nor 4L would parse as pre-processing
numbers, which of course they should.
David - please ignore that whole part of my previous message. Only the
following part is relevant:
> ... The far more conventional
>> way to handle this issue is to use the name space reserved to the
>> implementation. That's precisely the reason that name space was
>> reserved. You can use _Until or __until, and there's no parsing problems
>> and it is still a construct that can't appear in a strictly conforming
>> program.
>
> Right. The _Until form has become the conventional way to add new
> keywords; both C99 and C11 have added keywords with that general form,
> often along with a new header that defines a more convenient macro
> (see _Bool, <stdbool.h>, bool).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-14 08:45 -0700 |
| Message-ID | <b861aa1d-0fb8-4fd3-a695-c98f3c56a8b0@googlegroups.com> |
| In reply to | #65512 |
On Monday, July 13, 2015 at 12:18:56 PM UTC-7, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> > On 07/13/2015 01:34 PM, David Kleinecke wrote:
> [...]
> >> I see why I must not invent new keywords. No matter - there are plenty
> >> already. Perhaps I could invent "3until" because that's not going to
> >> appear in a strictlty conforming program - not even as "3" plus "until".
> >
> > That's ugly, and you have better options. However, before I go into
> > those other options, there's also another issue that's more important
> > than "that's ugly".
> >
> > During translation phase 3, "3until" must be parsed as a preprocessing
> > number ('3') followed by an identifier - keywords are not relevant until
> > phase 7. During translation phase 7, "Each preprocessing token is
> > converted into a token." - there's no merging and no splitting.
>
> Right.
>
> > Therefore, it must be parsed as the integer constant 3 followed by the
> > identifier "until".
>
> Hmm? As you just wrote, there's no splitting. The preprocessor number
> 3until is converted to a single token. Since 3until is not a
> syntactically valid token, it's a syntax error. It's not equivalent to
> the token 3 followed by the token until.
I dunno. 6.1.8 says that a pp-number can be, amomg other things,
a pp-number followed by a nondigit. I don't think nondigit is
defined anywhere so I just assume it means letter. That makes 3until
a legitimate pp-number. Still one token though but no error message.
>
> gcc complains:
> error: invalid suffix "until" on integer constant
>
> > You don't have to mess with the parsing rules. The far more conventional
> > way to handle this issue is to use the name space reserved to the
> > implementation. That's precisely the reason that name space was
> > reserved. You can use _Until or __until, and there's no parsing problems
> > and it is still a construct that can't appear in a strictly conforming
> > program.
>
> Right. The _Until form has become the conventional way to add new
> keywords; both C99 and C11 have added keywords with that general form,
> often along with a new header that defines a more convenient macro
> (see _Bool, <stdbool.h>, bool).
>
> --
> 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-07-14 09:05 -0700 |
| Message-ID | <lnegkalo6r.fsf@kst-u.example.com> |
| In reply to | #65553 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, July 13, 2015 at 12:18:56 PM UTC-7, Keith Thompson wrote:
[...]
>> Hmm? As you just wrote, there's no splitting. The preprocessor number
>> 3until is converted to a single token. Since 3until is not a
>> syntactically valid token, it's a syntax error. It's not equivalent to
>> the token 3 followed by the token until.
>
> I dunno. 6.1.8 says that a pp-number can be, amomg other things,
> a pp-number followed by a nondigit. I don't think nondigit is
> defined anywhere so I just assume it means letter. That makes 3until
> a legitimate pp-number. Still one token though but no error message.
In the current standard, one of the definitions of pp-number is:
pp-number identifier-nondigit
And of course "identifier-nondigit" is defined.
In C90, "nondigit" is defined in section 6.1.2. (I don't know why
you'd assume it's not defined.)
3until is a valid pp-number, but not a valid token. It's a
constraint violation that must be detected in translation phase 7.
6.4p2 (6.1 in C90) says:
Each preprocessing token that is converted to a token shall
have the lexical form of a keyword, an identifier, a constant,
a string literal, or a punctuator.
(I assumed it would be a syntax error; in fact the standard describes it
as a constraint violation. The distinction doesn't matter much, since
either requires a diagnostic.)
--
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-07-14 09:41 -0700 |
| Message-ID | <d02575a0-7335-42e2-87d7-4116af9a116e@googlegroups.com> |
| In reply to | #65559 |
On Tuesday, July 14, 2015 at 9:05:39 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Monday, July 13, 2015 at 12:18:56 PM UTC-7, Keith Thompson wrote: > [...] > >> Hmm? As you just wrote, there's no splitting. The preprocessor number > >> 3until is converted to a single token. Since 3until is not a > >> syntactically valid token, it's a syntax error. It's not equivalent to > >> the token 3 followed by the token until. > > > > I dunno. 6.1.8 says that a pp-number can be, amomg other things, > > a pp-number followed by a nondigit. I don't think nondigit is > > defined anywhere so I just assume it means letter. That makes 3until > > a legitimate pp-number. Still one token though but no error message. > > In the current standard, one of the definitions of pp-number is: > > pp-number identifier-nondigit > > And of course "identifier-nondigit" is defined. > > In C90, "nondigit" is defined in section 6.1.2. (I don't know why > you'd assume it's not defined.) > > 3until is a valid pp-number, but not a valid token. It's a > constraint violation that must be detected in translation phase 7. > 6.4p2 (6.1 in C90) says: > > Each preprocessing token that is converted to a token shall > have the lexical form of a keyword, an identifier, a constant, > a string literal, or a punctuator. > > (I assumed it would be a syntax error; in fact the standard describes it > as a constraint violation. The distinction doesn't matter much, since > either requires a diagnostic.) I don't know how I missed the definition of "nondigit" but I assumed it was exactly what it was. And you are right that an error will occur if nothing is done. But I think I could make an extension at this point and change "3until" into a keyword. Which is where this started. But I don't think I will ever want to do that because I now see that "__until" would do the job.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-14 10:26 -0700 |
| Message-ID | <lna8uylkfq.fsf@kst-u.example.com> |
| In reply to | #65566 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> And you are right that an error will occur if nothing is done. But
> I think I could make an extension at this point and change "3until"
> into a keyword. Which is where this started. But I don't think I will
> ever want to do that because I now see that "__until" would do the
> job.
"_Until" would probably be a better choice, just because it's consistent
with the way C99 and C11 have added new keywords.
But a language change is not really necessary; if you want to write
"until" loops, you can just do:
#define UNTIL(cond) while (!(cond))
I believe that would work for both while loops and do-while loops.
--
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-07-15 19:59 -0700 |
| Message-ID | <c680b941-64ae-4313-8444-da958adc6045@googlegroups.com> |
| In reply to | #65569 |
On Tuesday, July 14, 2015 at 10:26:44 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > And you are right that an error will occur if nothing is done. But
> > I think I could make an extension at this point and change "3until"
> > into a keyword. Which is where this started. But I don't think I will
> > ever want to do that because I now see that "__until" would do the
> > job.
>
> "_Until" would probably be a better choice, just because it's consistent
> with the way C99 and C11 have added new keywords.
>
> But a language change is not really necessary; if you want to write
> "until" loops, you can just do:
>
> #define UNTIL(cond) while (!(cond))
>
> I believe that would work for both while loops and do-while loops.
Quite so. I just thought up "until" as an easily understood example.
You are quite right that the macro does what I was playing with. If
I used the macro I'd also want
#define UNLESS(cond) if (!(cond))
However both suffer from the possibility that UNTIL (and UNLESS)
might conflict with other defined names.
But I've done this and while the code is skoosh more readable I
don't think it is worth the trouble.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-14 12:25 -0400 |
| Message-ID | <mo3d2d$128$1@dont-email.me> |
| In reply to | #65553 |
On 07/14/2015 11:45 AM, David Kleinecke wrote: > On Monday, July 13, 2015 at 12:18:56 PM UTC-7, Keith Thompson wrote: >> James Kuyper <jameskuyper@verizon.net> writes: ... >>> Therefore, it must be parsed as the integer constant 3 followed by the >>> identifier "until". >> >> Hmm? As you just wrote, there's no splitting. The preprocessor number >> 3until is converted to a single token. Since 3until is not a >> syntactically valid token, it's a syntax error. It's not equivalent to >> the token 3 followed by the token until. > > I dunno. 6.1.8 says that a pp-number can be, amomg other things, > a pp-number followed by a nondigit. I don't think nondigit is > defined anywhere so I just assume it means letter. ... In the current standard (sorry, I can't give you a C90 reference), pp-number actually references identifier-nondigit, which in turn refers to nondigit. Both identifier-nondigit and nondigit are defined in 6.4.2.1p1. nondigit is almost what you're suggesting, but it also include underscores. identifier-nondigit also allows universal-character-name, (a Unicode-related addition to C99), and other implementation-defined characters. The intent was for implementations to allow, at least as a option, writing identifiers using characters native to languages that can't be written using only the C basic character set. > ... That makes 3until > a legitimate pp-number. ... Yes, that was a mistake on my part. > ... Still one token though but no error message. It qualifies as a preprocessing-token, but it doesn't qualify as a token - it does not parse correctly for any of the token types listed in 6.4p1. As a result, it is a constraint violation (6.4p2) for which a diagnostic message is required. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-13 13:46 -0700 |
| Message-ID | <lnr3oblran.fsf@kst-u.example.com> |
| In reply to | #65507 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> During translation phase 3, "3until" must be parsed as a preprocessing
> number ('3') followed by an identifier - keywords are not relevant until
> phase 7. During translation phase 7, "Each preprocessing token is
> converted into a token." - there's no merging and no splitting.
[...]
The syntax for a "preprocessing number" is a bit odd. Obviously
"3until" isn't a number, but it is a preprocessing number. So is
".xyze+" -- but not ".xyzf+". "0x123" is a valid preprocessing number
-- and so is "0y123".
The reason, as far as I can tell, is to make the preprocessor's job
simpler. The syntax of a preprocessing number covers the syntax of all
integer and floating-point numeric constants, with or without decimal
points, base prefixes, exponents, and suffixes. It's designed to be
reasonably simple (you can see the grammar in N1570 6.4.8), and as a
result it covers a lot of things that aren't syntactically valid in
later phases; a grammar covering only *valid* numeric constants would be
more complicated. Translation phase 7 (more or less the compiler
excluding the preprocessor) is responsible for converting preprocessing
numbers to numeric constants, and diagnosing any that are invalid.
--
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-07-14 08:33 -0700 |
| Message-ID | <4474322c-262d-4d57-aafa-428c22a74612@googlegroups.com> |
| In reply to | #65507 |
On Monday, July 13, 2015 at 11:43:19 AM UTC-7, James Kuyper wrote:
> On 07/13/2015 01:34 PM, David Kleinecke wrote:
> > On Monday, July 13, 2015 at 9:39:11 AM UTC-7, James Kuyper wrote:
> >> On 07/13/2015 11:48 AM, David Kleinecke wrote:
> ...
> >>> But my attempt to describe extensions is restrictive. Could I perhaps
> >>> define more keywords? For example
> >>> until (...) {...}
> >>> with meaning "while not".
> >>
> >> 'until' is a name reserved to the users for all purposes. Therefore, a
> >> conforming implementation of C can't treat it as a keyword if it occurs
> >> in a strictly conforming program. However, if you use a construct with
> >> undefined behavior to turn on recognition of 'until' as a keyword, that
> >> would be allowed. You could also make recognition of 'until' as a
> >> keyword be controlled by a #pragma.
> >>
> >>> I think any of things would be an acceptable extension because any
> >>> correct strictly conforming program would not be impacted.
> >>
> >> Recognizing something as a keyword prevents it from being recognized as
> >> an identifier during translation phase 7. Any strictly conforming
> >> program that used 'until' as the name of an object, a function, a label,
> >> a struct/union/enumeration tag or member name would parse as a syntax
> >> error if your compiler recognizes it as a keyword instead.
> ...
> > I see why I must not invent new keywords. No matter - there are plenty
> > already. Perhaps I could invent "3until" because that's not going to
> > appear in a strictlty conforming program - not even as "3" plus "until".
>
> That's ugly, and you have better options. However, before I go into
> those other options, there's also another issue that's more important
> than "that's ugly".
>
> During translation phase 3, "3until" must be parsed as a preprocessing
> number ('3') followed by an identifier - keywords are not relevant until
> phase 7. During translation phase 7, "Each preprocessing token is
> converted into a token." - there's no merging and no splitting.
> Therefore, it must be parsed as the integer constant 3 followed by the
> identifier "until". Now, you can specify the grammar for your extension
> as saying that this combination of tokens has the effect that you
> desire. However, by the general rules specified for parsing C code, if
> "3until" has that effect, then so should "3 until", "3\tuntil" and
> "3\nuntil". That's because white space separating tokens gets dropped
> during translation phase 7. I don't think you would want it to work that
> way.
>
> Either way, as you say, it's a syntax error, and thus a legitimate basis
> for triggering a conforming extension - and perhaps that extension could
> involve parsing this particular construct differently. However, if I
> were trying to make this work, I'd be worried that modifying the parsing
> rules to allow 3until to be parsed as a single keyword, might result in
> something else breaking, possibly in ways that would affect even
> strictly conforming code. I haven't come up with any examples yet, so
> count that as a vague uneasiness rather than a solid objection.
>
> You don't have to mess with the parsing rules. The far more conventional
> way to handle this issue is to use the name space reserved to the
> implementation. That's precisely the reason that name space was
> reserved. You can use _Until or __until, and there's no parsing problems
> and it is still a construct that can't appear in a strictly conforming
> program.
Yes - that's more or less what I concluded. But thanks for that last
idea - I missed it. I may not approve of the leading underscore rules
but a strictly-conforming program will obey them. Much better that
rying to use '3".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-13 11:17 -0700 |
| Message-ID | <ln8uajncr9.fsf@kst-u.example.com> |
| In reply to | #65494 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> It's also not what the standard says. If the parse fails, you have a
> syntax error, and the program is not strictly conforming, so a
> conforming extension is allowed to to alter the behavior of such a
> program. However, having a parse failure is not the only way that an
> extension can change the behavior - anything that prevents a program
> from being strictly conforming could also be the basis for a conforming
> extension. Other possibilities:
> 1. constraint violation
> 2. code with undefined behavior
> 3. code with unspecified behavior
> 4. code with implementation-defined behavior
> 5. code which exceeds any of the minimum implementation limits.
I wouldn't call cases 2, 3, and 4 "extensions". A conforming
implementation with no extensions can still do what it likes within the
bounds of what the standard says about undefined, unspecified, and
implementation-defined behavior.
The meaning of "extension" is a bit vague -- but I'm not aware of any
case where that vagueness has been a real problem.
[...]
--
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 Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-13 21:06 -0400 |
| Message-ID | <pgZox.89723$722.67967@fx14.iad> |
| In reply to | #65494 |
On 7/13/15 12:38 PM, James Kuyper wrote: ... > 5. code which exceeds any of the minimum implementation limits. > > The third case is somewhat restrictive: the only kind of extension you > can provide that way is one that involves making a specific choice among > the possibilities allowed by the standard. The fourth one is even more > restricted - you must document the choice, and your compiler must > implement that choice. The other three cases all give you pretty much > unlimited freedom to do whatever you want. > I don't think exceeding a minimum implementation limit gives your free reign to define new behavior. The behavior of such a program is still defined by the standard. The implementation limits section just allows an implementation the right to 'give up' on a program and say it exceeds the implementation's capacity, while defining a minimum set of limits that that the implementation must take in a (not any) program. By the wording of the standard (unless they have changed it), a given program doesn't need to exceed any of the stated minimum requirements for the implementation to use that clause and give up on the program.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-13 22:38 -0400 |
| Message-ID | <mo1sk0$6r3$1@dont-email.me> |
| In reply to | #65530 |
On 07/13/2015 09:06 PM, Richard Damon wrote: > On 7/13/15 12:38 PM, James Kuyper wrote: > ... >> 5. code which exceeds any of the minimum implementation limits. > > >> The third case is somewhat restrictive: the only kind of extension you >> can provide that way is one that involves making a specific choice among >> the possibilities allowed by the standard. The fourth one is even more >> restricted - you must document the choice, and your compiler must >> implement that choice. The other three cases all give you pretty much >> unlimited freedom to do whatever you want. >> > > I don't think exceeding a minimum implementation limit gives your free > reign to define new behavior. The behavior of such a program is still > defined by the standard. > > The implementation limits section just allows an implementation the > right to 'give up' on a program and say it exceeds the implementation's > capacity, while defining a minimum set of limits that that the > implementation must take in a (not any) program. By the wording of the > standard (unless they have changed it), a given program doesn't need to > exceed any of the stated minimum requirements for the implementation to > use that clause and give up on the program. The implementation limits have two key effects: 1. For any given conforming implementation of C, there must be at least one program which simultaneously meets or exceeds all of those limits, and which can be translated an executed by that implementation. There is no other program that any implementation of C is ever required to translate and execute. 2. No strictly conforming program is allowed to exceed any of those minimum limits. After defining the term "strictly conforming", the standard only says two things about strictly conforming programs: they must be accepted by a conforming implementation (which does not mean it needs to be translated or executed - simply printing "program accepted" meets this requirement). And conforming extensions are only prohibited from changing the behavior of a strictly conforming program. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web