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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-15 08:19 -0400 |
| Message-ID | <8dspx.57455$Xi4.27916@fx09.iad> |
| In reply to | #65534 |
On 7/13/15 10:38 PM, James Kuyper wrote: > 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. > I think you overstate the last part. The standard states that extension may not change the behavior of strictly conforming programs (it doesn't use the term 'only'). This does NOT imply that just because a program isn't 'strictly conforming' the standard does provide behavior of the program. The standard DOES provide limitations on the behavior of many non-strictly conforming programs (which is a category most programs fall into, so this is good) and a conforming implementation needs to provide this behavior, or fail to translate due to exceeding implementation limits. (If a program has undefined behavior, or violates a constraint, then the implementation has free reign on behavior). Thus, just because a program does something like define an object like char buffer[100000]; (Note, that is enough to exceed implementation limits!, but is legal in many implementations if SIZE_MAX is large enough) This doesn't say that the implementation is now free to 'extend' the language and not provide all the behavior required by the standard for the rest of the program. I will admit that I don't understand the reasoning for needed that clause, as it seems tautological, since strictly conforming programs have their behavior fully defined by the standard, and leave no room for implementation or unspecified behavior, of course an implementation can't 'extend' the language to change that behavior, it make the implementation non-conforming! (Maybe the clause was put in as a backstop so in case someone finds some wiggle room somewhere, this requirement makes the need for the implementation to conform to the standard clear). To say that the mere fact that a program isn't strictly conforming allows the implementation to 'extend' the language and change standard defined behavior would be a bigger hole than the perverse interpretation of implementation limits to allow the implementation to only allow the execution of that 'one program' and the rest are all aborted on a failure due to implementation limits (note, the right of the implementation to call on the implementation limits clause is NOT restricted to programs that exceed a defined limit).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 09:10 -0700 |
| Message-ID | <kfnegk2olm4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65617 |
Richard Damon <Richard@Damon-Family.org> writes: > (If a program has undefined behavior, or violates a constraint, > then the implementation has free reign on behavior). <grammatical-nit> Unless you think a monarch is involved, that is free rein, not free reign. </grammatical-nit>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-13 11:00 -0700 |
| Message-ID | <lnd1zwlyy6.fsf@kst-u.example.com> |
| In reply to | #65489 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, July 12, 2015 at 11:24:15 AM UTC-7, Keith Thompson wrote:
[...]
>> 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.
Yes, that would be a valid extension. A conforming compiler must still
diagnose `if` followed by `[`, but once it's done that it can behave as
it likes.
I know I'm not completely answering your question about what an
extension is.
One potentially troubling point:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
A hypothetical "extension" that alters the behavior of
printf("%d\n", INT_MAX);
would not violate this rule, but IMHO it should not be considered valid.
> 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.
`until` is a valid identifier. Treating it as a keyword would break
strictly conforming programs.
Treating it as a keyword only in contexts where it could not appear as
an identifier might be possible. IMHO that would be overly confusing.
For example, this:
until (x == 42);
would presumably be an "until" loop with an empty body -- but it's
already syntactically valid as an expression statement containing a call
to a function named "until".
> Are C99, C11, etc. extensions of C90?
Strictly speaking, no. Among other things, C99 dropped the
"implicit int" rule, and both C99 and C11 added new keywords, so
there are strictly conforming C90 programs that are not valid C99
or C11 programs:
main(void) {
int restrict = 0;
return restrict;
}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 08:11 -0700 |
| Message-ID | <kfn8uahsbg9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65415 |
David Kleinecke <dkleinecke@gmail.com> writes: > 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. [snip] If you can't remember what it is you read you're really not in a position to say whether or not it is clear on a particular point.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-27 10:57 -0700 |
| Message-ID | <878uc9nbrw.fsf@kst-u.example.com> |
| In reply to | #62677 |
David Kleinecke <dkleinecke@gmail.com> writes:
> 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.
You have not answered my question.
What is your interpretation of this sentence in the standard?
All predefined macro names shall begin with a leading underscore
followed by an uppercase letter or a second underscore.
If predefined macros other than the listed ones were not allowed,
that sentence would be meaningless. Do you believe it's meaningless?
If so, why do you think it was included?
Furthermore, suppose we interpret the standard in a way that forbids
predefined macros other than the ones that are explicitly listed.
Suppose I have a compiler that is 100% conforming except that
it predefines __unix as a macro that expands to the constant 1.
What clause of the standard does this compiler violate? Is there a
strictly conforming program that it would fail to process correctly,
or a required diagnostic message that it would fail to emit?
Please be specific.
The standard does not explicitly allow a compiler to print error
messages in bold text. Does a compiler that does so therefore
violate the standard?
The standard is written in English, not in formal mathematics.
Reading it requires some common sense.
--
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-24 09:51 -0700 |
| Message-ID | <38aa2597-41d3-4b49-8093-f443b0fbdbc6@googlegroups.com> |
| In reply to | #62506 |
On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote:
> And a C90 compiler is permitted to predefine such a
> macro even without an explicit #define in any header. Any program
> that declares or defines such an identifier *even without including
> any standard header* has undefined behavior. The standard explicitly
> says so. (It's 7.1.3 paragraphs 1 and 2 in C11; my copy of the
> C90 standard is difficult to search, but I'm sure you can find
> it yourself.)
In my copy of the C90 standard 7.1.3 is the section about reserved
identifiers. I cannot find the words "even without including any
standard header has undefined behavior."
As I read what you wrote you believe that a compiler can define a
macro prior to any tanslation unit - something I believe does not
happen - but the standard says the behavior is undefined and that,
because the behavior is undefined it can be anything the
implementation makes of it.
If I understand you correctly I believe you are at least admitting
the existence of some very bad practice. I would consider any use
of undefined behavior a coding error - it is not transferable.
> > A program could make a structure tag a macro reference but it is hard
> > see a reason to do so. In any case were _GeditTab a macro reference the
> > preprocessor would change it and it would never interfer with a library
> > reference.
>
> If an implementation defines _GeditTab as, for example, void (for
> whatever reason), then the declaration
> struct _GeditTab { ... };
> will fail to compile. It's unlikely to happen in practice, but it's
> perfectly legal for an implementation to do so. By defining _GeditTab,
> even as a struct tag, that library risks conflicting with some
> conforming C implementation. It's probably a small risk, and apparently
> one that the implementers of the library have chosen to accept, but it's
> non-zero -- and could have been avoided by choosing a non-reserved
> identifier.
>
> --
> 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-24 13:36 -0700 |
| Message-ID | <87egm5pvb1.fsf@kst-u.example.com> |
| In reply to | #62533 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote:
>> And a C90 compiler is permitted to predefine such a
>> macro even without an explicit #define in any header. Any program
>> that declares or defines such an identifier *even without including
>> any standard header* has undefined behavior. The standard explicitly
>> says so. (It's 7.1.3 paragraphs 1 and 2 in C11; my copy of the
>> C90 standard is difficult to search, but I'm sure you can find
>> it yourself.)
>
> In my copy of the C90 standard 7.1.3 is the section about reserved
> identifiers. I cannot find the words "even without including any
> standard header has undefined behavior."
Of course not. That was my conclusion from what that section says.
I never claimed those exact words were there. If I had been quoting
from the standard, I would have used quotation marks.
> As I read what you wrote you believe that a compiler can define a
> macro prior to any tanslation unit - something I believe does not
> happen - but the standard says the behavior is undefined and that,
> because the behavior is undefined it can be anything the
> implementation makes of it.
Yes. To be clear, the behavior of a program that declares or defines a
reserved identifier is undefined.
> If I understand you correctly I believe you are at least admitting
> the existence of some very bad practice. I would consider any use
> of undefined behavior a coding error - it is not transferable.
The use of a reserved identifier in the code in question causes
that code to have undefined behavior (behavior that is not
defined by the C standard). It's not a choice I would have made;
on the other hand, a lot of useful code has undefined behavior.
Probably the authors decided the advantages of using that identifier
(and avoiding collisions with user code) outweighed the risks.
I don't know what you think I'm "admitting", nor do I understand
what you mean by "it is not transferable".
[...]
--
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-25 10:00 -0700 |
| Message-ID | <25997950-31c5-4ca5-98d5-b7e51494b0e5@googlegroups.com> |
| In reply to | #62544 |
On Sunday, May 24, 2015 at 1:36:30 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > If I understand you correctly I believe you are at least admitting > > the existence of some very bad practice. I would consider any use > > of undefined behavior a coding error - it is not transferable. > > The use of a reserved identifier in the code in question causes > that code to have undefined behavior (behavior that is not > defined by the C standard). It's not a choice I would have made; > on the other hand, a lot of useful code has undefined behavior. > Probably the authors decided the advantages of using that identifier > (and avoiding collisions with user code) outweighed the risks. > > I don't know what you think I'm "admitting", nor do I understand > what you mean by "it is not transferable". I used "admit" because I didn't want to accuse you of advocating. And I meant "portable".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-25 13:05 -0700 |
| Message-ID | <877frwo21n.fsf@kst-u.example.com> |
| In reply to | #62605 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, May 24, 2015 at 1:36:30 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> > If I understand you correctly I believe you are at least admitting
>> > the existence of some very bad practice. I would consider any use
>> > of undefined behavior a coding error - it is not transferable.
>>
>> The use of a reserved identifier in the code in question causes
>> that code to have undefined behavior (behavior that is not
>> defined by the C standard). It's not a choice I would have made;
>> on the other hand, a lot of useful code has undefined behavior.
>> Probably the authors decided the advantages of using that identifier
>> (and avoiding collisions with user code) outweighed the risks.
>>
>> I don't know what you think I'm "admitting", nor do I understand
>> what you mean by "it is not transferable".
>
> I used "admit" because I didn't want to accuse you of advocating.
Advocating what?
> And I meant "portable".
Ok.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-05-24 16:43 -0700 |
| Message-ID | <MPG.2fcc01f362a7d79029@news.eternal-september.org> |
| In reply to | #62533 |
David Kleinecke wrote: > Keith Thompson wrote: > > And a C90 compiler is permitted to predefine such a > > macro even without an explicit #define in any header. Any program > > that declares or defines such an identifier *even without including > > any standard header* has undefined behavior. The standard explicitly > > says so. (It's 7.1.3 paragraphs 1 and 2 in C11; my copy of the > > C90 standard is difficult to search, but I'm sure you can find > > it yourself.) > > As I read what you wrote you believe that a compiler can define a > macro prior to any tanslation unit - something I believe does not > happen - but the standard says the behavior is undefined and that, > because the behavior is undefined it can be anything the > implementation makes of it. I can't imagine where you got the idea that a compiler cannot define a macro prior to any translation unit. Every C compiler I've ever used does that. The earliest ones defined the symbol "unix" equal to 1, for example. Current compilers don't do that, because it wouldn't be standard-conforming, but I suspect many C compilers define the macro __unix. The compiler I use defines symbols such as __linux and __STDC__ and __CHAR_BIT__. (Note that one of those definitions is not only allowed, but required, by all versions of the C standard.) > If I understand you correctly I believe you are at least admitting > the existence of some very bad practice. I would consider any use > of undefined behavior a coding error - it is not transferable. I'm not sure what "bad practice" you are referring to. Definition of reserved symbols by the compiler is not bad practice. (It's why they're reserved for the implementation.) Use of these reserved symbols in the way that the implementation intends them to be used is not bad practice, although they may make the code non-portable. (Said usage may also make the code *more* portable.) Use of reserved symbols in a way that is not intended by the implementation or allowed by the standard is bad practice, and I don't think Keith was condoning that, although he and I have each certainly seen plenty of bad practice, including that. Philip
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-24 09:57 -0700 |
| Message-ID | <78c97d0b-fd34-41ed-aa2b-fe31a4ab393c@googlegroups.com> |
| In reply to | #62506 |
On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
>
> > A program could make a structure tag a macro reference but it is hard
> > see a reason to do so. In any case were _GeditTab a macro reference the
> > preprocessor would change it and it would never interfer with a library
> > reference.
>
> If an implementation defines _GeditTab as, for example, void (for
> whatever reason), then the declaration
> struct _GeditTab { ... };
> will fail to compile. It's unlikely to happen in practice, but it's
> perfectly legal for an implementation to do so. By defining _GeditTab,
> even as a struct tag, that library risks conflicting with some
> conforming C implementation. It's probably a small risk, and apparently
> one that the implementers of the library have chosen to accept, but it's
> non-zero -- and could have been avoided by choosing a non-reserved
> identifier.
I thought of that but discounted it. The code would not compile because
"void" is a keyword and not an identifier. The library is never involved.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-24 13:37 -0700 |
| Message-ID | <87a8wtpv8a.fsf@kst-u.example.com> |
| In reply to | #62534 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> > A program could make a structure tag a macro reference but it is hard
>> > see a reason to do so. In any case were _GeditTab a macro reference the
>> > preprocessor would change it and it would never interfer with a library
>> > reference.
>>
>> If an implementation defines _GeditTab as, for example, void (for
>> whatever reason), then the declaration
>> struct _GeditTab { ... };
>> will fail to compile. It's unlikely to happen in practice, but it's
>> perfectly legal for an implementation to do so. By defining _GeditTab,
>> even as a struct tag, that library risks conflicting with some
>> conforming C implementation. It's probably a small risk, and apparently
>> one that the implementers of the library have chosen to accept, but it's
>> non-zero -- and could have been avoided by choosing a non-reserved
>> identifier.
>
> I thought of that but discounted it. The code would not compile because
> "void" is a keyword and not an identifier. The library is never involved.
Huh?
The declaration `struct _GeditTab` is part of the library. That code
has undefined behavior because of its use of a reserved identifier. The
code failing to compile because "void" is a keyword is one possible
consequence of the undefined behavior.
--
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-25 10:14 -0700 |
| Message-ID | <a8c09526-9f66-4ef8-98de-41c86288bc4e@googlegroups.com> |
| In reply to | #62545 |
On Sunday, May 24, 2015 at 1:38:06 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >>
> >> > A program could make a structure tag a macro reference but it is hard
> >> > see a reason to do so. In any case were _GeditTab a macro reference the
> >> > preprocessor would change it and it would never interfer with a library
> >> > reference.
> >>
> >> If an implementation defines _GeditTab as, for example, void (for
> >> whatever reason), then the declaration
> >> struct _GeditTab { ... };
> >> will fail to compile. It's unlikely to happen in practice, but it's
> >> perfectly legal for an implementation to do so. By defining _GeditTab,
> >> even as a struct tag, that library risks conflicting with some
> >> conforming C implementation. It's probably a small risk, and apparently
> >> one that the implementers of the library have chosen to accept, but it's
> >> non-zero -- and could have been avoided by choosing a non-reserved
> >> identifier.
> >
> > I thought of that but discounted it. The code would not compile because
> > "void" is a keyword and not an identifier. The library is never involved.
>
> Huh?
>
> The declaration `struct _GeditTab` is part of the library. That code
> has undefined behavior because of its use of a reserved identifier. The
> code failing to compile because "void" is a keyword is one possible
> consequence of the undefined behavior.
Where do you imagine identifier reservation is tested?
In my model of compilers it could be tested in the tokenizer. So that
the moment the tokenizer reads in _GeditTab the whole compilation goes
implementor dependent.
The preprocesor and the parser are other possibilities.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-25 13:11 -0700 |
| Message-ID | <87382ko1s8.fsf@kst-u.example.com> |
| In reply to | #62606 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> Where do you imagine identifier reservation is tested?
>
> In my model of compilers it could be tested in the tokenizer. So that
> the moment the tokenizer reads in _GeditTab the whole compilation goes
> implementor dependent.
>
> The preprocesor and the parser are other possibilities.
Why do you imagine it needs to be tested? It doesn't.
A program that defines a reserved identifier has undefined behavior.
There is no requirement for this to be detected or diagnosed.
As it happens, most implementations do not distinguish between reserved
and unreserved identifiers. If I write
int main(void) {
int __Reserved = 0;
return __Reserved;
}
my program has undefined behavior. If the implementation I'm using
doesn't happen to use the name __Reserved, it will *probably* treat it
as an ordinary identifier, and my program will *probably* behave
identically to a program that uses "foo" rather than "__Reserved".
A compiler *may* diagnose, or even reject, code that misuses reserved
identifiers, but it's not required, and I don't know of any compilers
that do so.
You suggest that "the whole compilation goes implementor dependent".
What do you imagine that means?
--
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 10:26 -0700 |
| Message-ID | <79990f26-f4e8-4b3c-8329-e3a122195ab0@googlegroups.com> |
| In reply to | #62615 |
On Monday, May 25, 2015 at 1:11:42 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > Where do you imagine identifier reservation is tested?
> >
> > In my model of compilers it could be tested in the tokenizer. So that
> > the moment the tokenizer reads in _GeditTab the whole compilation goes
> > implementor dependent.
> >
> > The preprocesor and the parser are other possibilities.
>
> Why do you imagine it needs to be tested? It doesn't.
>
> A program that defines a reserved identifier has undefined behavior.
> There is no requirement for this to be detected or diagnosed.
> As it happens, most implementations do not distinguish between reserved
> and unreserved identifiers. If I write
>
> int main(void) {
> int __Reserved = 0;
> return __Reserved;
> }
>
> my program has undefined behavior. If the implementation I'm using
> doesn't happen to use the name __Reserved, it will *probably* treat it
> as an ordinary identifier, and my program will *probably* behave
> identically to a program that uses "foo" rather than "__Reserved".
>
> A compiler *may* diagnose, or even reject, code that misuses reserved
> identifiers, but it's not required, and I don't know of any compilers
> that do so.
>
> You suggest that "the whole compilation goes implementor dependent".
> What do you imagine that means?
No longer needs follow any conventional rules - including the standard
or what the programmer intended. It could insert hostile code, for
example.
It appears that we need a definition of "undefined" and the standard
provides one. In C90 "undefined behavior" means "behavior ... for which
this international standard imposes no requirements. Permissible
undefined behavior ..."
I think that is amusing. It imposes no requirements and immediately
starts imposing requirements. The standard goes on "... ranges from
ignoring the situation completely with unpredictable results, to
behaving during translation or program excution in a documented
manner chacteristic of the environment ... to terminating a
translation or execution ..."
Later on it says " Undefined behavior is indicated in this IS ...
by the omission of any explicit definition of behavior ...". This
clause would seem to me make additional pre-defined macros undefined
behavior.
It seems to me that you agree that, practially speaking, the reserved
identifier idea has no effect that depends on reservation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-26 18:38 +0100 |
| Message-ID | <mk2b1b$t9k$1@dont-email.me> |
| In reply to | #62649 |
On 26/05/15 18:26, David Kleinecke wrote: <snip> > It appears that we need a definition of "undefined" and the standard > provides one. In C90 "undefined behavior" means "behavior ... for which > this international standard imposes no requirements. Permissible > undefined behavior ..." > > I think that is amusing. It imposes no requirements and immediately > starts imposing requirements. It's not as funny as you might think, given the nature of the imposition, which you go on to cite: > The standard goes on "... ranges from > ignoring the situation completely with unpredictable results, In other words, the implementation is given complete licence to do anything whatsoever. That isn't much of a restriction, is it? <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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-26 12:24 -0700 |
| Message-ID | <87lhgbm99y.fsf@kst-u.example.com> |
| In reply to | #62649 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, May 25, 2015 at 1:11:42 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > Where do you imagine identifier reservation is tested?
>> >
>> > In my model of compilers it could be tested in the tokenizer. So that
>> > the moment the tokenizer reads in _GeditTab the whole compilation goes
>> > implementor dependent.
>> >
>> > The preprocesor and the parser are other possibilities.
>>
>> Why do you imagine it needs to be tested? It doesn't.
>>
>> A program that defines a reserved identifier has undefined behavior.
>> There is no requirement for this to be detected or diagnosed.
>
>> As it happens, most implementations do not distinguish between reserved
>> and unreserved identifiers. If I write
>>
>> int main(void) {
>> int __Reserved = 0;
>> return __Reserved;
>> }
>>
>> my program has undefined behavior. If the implementation I'm using
>> doesn't happen to use the name __Reserved, it will *probably* treat it
>> as an ordinary identifier, and my program will *probably* behave
>> identically to a program that uses "foo" rather than "__Reserved".
>>
>> A compiler *may* diagnose, or even reject, code that misuses reserved
>> identifiers, but it's not required, and I don't know of any compilers
>> that do so.
>>
>> You suggest that "the whole compilation goes implementor dependent".
>> What do you imagine that means?
>
> No longer needs follow any conventional rules - including the standard
> or what the programmer intended. It could insert hostile code, for
> example.
Yes. The behavior is undefined. No particular thing necessarily
happens when a program's behavior becomes undefined; it could easily
behave exactly as you expect it to (whatever your expectations
happen to be).
> It appears that we need a definition of "undefined" and the standard
> provides one. In C90 "undefined behavior" means "behavior ... for which
> this international standard imposes no requirements. Permissible
> undefined behavior ..."
>
> I think that is amusing. It imposes no requirements and immediately
> starts imposing requirements. The standard goes on "... ranges from
> ignoring the situation completely with unpredictable results, to
> behaving during translation or program excution in a documented
> manner chacteristic of the environment ... to terminating a
> translation or execution ..."
No, it does not "immediately start[] imposing requirements".
It gives concrete examples of some of the infinitely many possible
consequences of undefined behavior. The wording starting with
"Permissible undefined behavior" could be omitted without changing
the normative meaning; it's there to add clarity.
> Later on it says " Undefined behavior is indicated in this IS ...
> by the omission of any explicit definition of behavior ...". This
> clause would seem to me make additional pre-defined macros undefined
> behavior.
Undefined behavior refers to behavior *of a program* that is not defined
by the standard, not behavior of an implementation.
A conforming implementation may define additional predefined macros
whose names are reserved identifiers. A program that declares or
defines a reserved identifier has undefined behavior (whether the
current implementation happens to predefine it or not).
> It seems to me that you agree that, practially speaking, the reserved
> identifier idea has no effect that depends on reservation.
No, I didn't say that. What I said is that there is an implementation
is not required to detect or diagnose a program that improperly uses
reserved identifiers. It *may* do so.
Two concrete examples:
Both of these programs:
int main(void) {
int __FOOBAR = 0;
return __FOOBAR;
}
and
int main(void) {
int __unix = 0;
return __unix;
}
have undefined behavior because each of them defines a reserved
identifier. The first one behaves *on my system* in the same way
that it would if I replaced __FOOBAR by a non-reserved identifier.
The second fails to compile (because __unix is predefined as a
macro expanding to 1).
The latter is a practical effect of reserved identifiers.
--
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:06 -0700 |
| Message-ID | <ea66c335-c200-4ac3-9c39-b7eb1819e121@googlegroups.com> |
| In reply to | #62661 |
On Tuesday, May 26, 2015 at 12:25:11 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, May 25, 2015 at 1:11:42 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > Where do you imagine identifier reservation is tested?
> >> >
> >> > In my model of compilers it could be tested in the tokenizer. So that
> >> > the moment the tokenizer reads in _GeditTab the whole compilation goes
> >> > implementor dependent.
> >> >
> >> > The preprocesor and the parser are other possibilities.
> >>
> >> Why do you imagine it needs to be tested? It doesn't.
> >>
> >> A program that defines a reserved identifier has undefined behavior.
> >> There is no requirement for this to be detected or diagnosed.
> >
> >> As it happens, most implementations do not distinguish between reserved
> >> and unreserved identifiers. If I write
> >>
> >> int main(void) {
> >> int __Reserved = 0;
> >> return __Reserved;
> >> }
> >>
> >> my program has undefined behavior. If the implementation I'm using
> >> doesn't happen to use the name __Reserved, it will *probably* treat it
> >> as an ordinary identifier, and my program will *probably* behave
> >> identically to a program that uses "foo" rather than "__Reserved".
> >>
> >> A compiler *may* diagnose, or even reject, code that misuses reserved
> >> identifiers, but it's not required, and I don't know of any compilers
> >> that do so.
> >>
> >> You suggest that "the whole compilation goes implementor dependent".
> >> What do you imagine that means?
> >
> > No longer needs follow any conventional rules - including the standard
> > or what the programmer intended. It could insert hostile code, for
> > example.
>
> Yes. The behavior is undefined. No particular thing necessarily
> happens when a program's behavior becomes undefined; it could easily
> behave exactly as you expect it to (whatever your expectations
> happen to be).
>
> > It appears that we need a definition of "undefined" and the standard
> > provides one. In C90 "undefined behavior" means "behavior ... for which
> > this international standard imposes no requirements. Permissible
> > undefined behavior ..."
> >
> > I think that is amusing. It imposes no requirements and immediately
> > starts imposing requirements. The standard goes on "... ranges from
> > ignoring the situation completely with unpredictable results, to
> > behaving during translation or program excution in a documented
> > manner chacteristic of the environment ... to terminating a
> > translation or execution ..."
>
> No, it does not "immediately start[] imposing requirements".
> It gives concrete examples of some of the infinitely many possible
> consequences of undefined behavior. The wording starting with
> "Permissible undefined behavior" could be omitted without changing
> the normative meaning; it's there to add clarity.
>
> > Later on it says " Undefined behavior is indicated in this IS ...
> > by the omission of any explicit definition of behavior ...". This
> > clause would seem to me make additional pre-defined macros undefined
> > behavior.
>
> Undefined behavior refers to behavior *of a program* that is not defined
> by the standard, not behavior of an implementation.
>
> A conforming implementation may define additional predefined macros
> whose names are reserved identifiers. A program that declares or
> defines a reserved identifier has undefined behavior (whether the
> current implementation happens to predefine it or not).
>
> > It seems to me that you agree that, practially speaking, the reserved
> > identifier idea has no effect that depends on reservation.
>
> No, I didn't say that. What I said is that there is an implementation
> is not required to detect or diagnose a program that improperly uses
> reserved identifiers. It *may* do so.
>
> Two concrete examples:
>
> Both of these programs:
>
> int main(void) {
> int __FOOBAR = 0;
> return __FOOBAR;
> }
>
> and
>
> int main(void) {
> int __unix = 0;
> return __unix;
> }
>
> have undefined behavior because each of them defines a reserved
> identifier. The first one behaves *on my system* in the same way
> that it would if I replaced __FOOBAR by a non-reserved identifier.
> The second fails to compile (because __unix is predefined as a
> macro expanding to 1).
>
> The latter is a practical effect of reserved identifiers.
So ???
I see no reason why using "__unix" is better than using "unix". Just
showing how a mechanism works is not a demonstration of why it is
imperative or superior.
This comment applies all through your post so I wont snip it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-27 11:05 -0700 |
| Message-ID | <874mmxnbg3.fsf@kst-u.example.com> |
| In reply to | #62678 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, May 26, 2015 at 12:25:11 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> > It seems to me that you agree that, practially speaking, the reserved
>> > identifier idea has no effect that depends on reservation.
>>
>> No, I didn't say that. What I said is that there is an implementation
>> is not required to detect or diagnose a program that improperly uses
>> reserved identifiers. It *may* do so.
>>
>> Two concrete examples:
>>
>> Both of these programs:
>>
>> int main(void) {
>> int __FOOBAR = 0;
>> return __FOOBAR;
>> }
>>
>> and
>>
>> int main(void) {
>> int __unix = 0;
>> return __unix;
>> }
>>
>> have undefined behavior because each of them defines a reserved
>> identifier. The first one behaves *on my system* in the same way
>> that it would if I replaced __FOOBAR by a non-reserved identifier.
>> The second fails to compile (because __unix is predefined as a
>> macro expanding to 1).
>>
>> The latter is a practical effect of reserved identifiers.
>
> So ???
So, you're mistaken.
You said that "the reserved identifier idea has no effect that depends
on reservation" (and mistakenly thought that I agreed). I demonstrated
a case where the reserved identifier idea *does* have an effect that
depends on reservation.
> I see no reason why using "__unix" is better than using "unix".
Seriously? I've been trying to explain it to you.
Certain identifiers, including "__unix", are reserved for use by the
implementation. Other identifiers, including "unix", are reserved for
use by user programs.
Without this mechanism or something like it, it would be impossible to
write portable code. I could write:
int i = 42;
today, and tomorrow a compiler could decide to define "i" as a macro in
some standard header.
> Just
> showing how a mechanism works is not a demonstration of why it is
> imperative or superior.
My example was not intended to show why it's "imperative or
superior", merely to show how it works. As it happens, it *is*
superior to not having reserved identifiers at all (which was the
state before the ANSI C standard). I am astonished that you don't
understand that.
If you'd prefer a different mechanism, I agree; if I were designing a
new language from scratch, without concern for breaking existing code, I
would do something different to avoid collisions. You seem to advocate
throwing away the only such mechanism we currently have in C and not
replacing it with anything. I have tried to explain, among other
things, why that would be a bad idea.
--
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 10:38 -0700 |
| Message-ID | <5440744e-91f5-455c-9327-2da1af354d13@googlegroups.com> |
| In reply to | #62506 |
On Tuesday, May 26, 2015 at 9:06:17 AM UTC-7, James Kuyper wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> ...
> > At the C90 level an implementation can't define a macro. Only those
> > macros defined in a translation unit or included in it are
> > recognized.
>
> Do you know of any C90 compiler which, when asked to compile the
> following code, triggers one or more of the #error directives?
> =======================================================================
> #ifndef __DATE__
> #error __DATE__ not #defined
> #endif
>
> #ifndef __FILE__
> #error __FILE__ not #defined.
> #endif
>
> #ifndef __LINE__
> #error __LINE__ not #defined.
> #endif
>
> #ifndef __STDC__
> #error __STDC__ not #defined.
> #endif
>
> #ifndef __TIME__
> #error __TIME__ not #defined.
> #endif
>
> /* To avoid warnings about not defining anything. */
> void dummy_func(void) {return;}
> =======================================================================
> Note: I've never owned a copy of C90; the oldest version of the standard
> that I've actually read was C99. Therefore, while I'm fairly certain
> that pre#definition of all of those macros was mandatory, I may be
> incorrect about one or more of them.
I may do odd things but collect old compilers is not one of them. I
don't think I have anything but current gcc on my machine.
I did myself write the front end of a compiler to test some optimization
ideas (but never pushed it into actual machine code). My "compiler"
would kick out all five errors because I intentionally left out every
thing I didn't need. I agree that that shouldn't count in the answer to
your question.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web