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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-20 12:08 -0500 |
| Message-ID | <mjiel8$f7c$1@dont-email.me> |
| In reply to | #62344 |
David Kleinecke wrote: > On Tuesday, May 19, 2015 at 11:23:48 AM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: > >> I asked you a few days ago: >> >> [...] Do you think that identifiers starting with underscores >> *shouldn't* be reserved to the implementation? If so, how are >> implementations of the standard library supposed to be written >> without the risk of breaking user code? >> >> I don't recall that you ever replied. > > I didn't reply. > > Yes - I don't think there should be any reserved identifiers. > There must be reserved identifiers. > If people have been obeying the rules so far there is no user code to > break by abolishing identifier reservation. > Ummmm... but you've greatly increased the cost to the compiler. 'C' source is not a floating abstract object; it has very real physical referents as part of its basic design. The Java/Haskell/Lisp groups are thataway. Even then... > Future conflicts between identifiers in the standard library can be > handled in whatever fashion conflicts between identifiers in two pieces > of user code are handled. > You *CAN* reuse reserved identifiers by: - macro substitution. - the use of the "static" keyword But you should not. Because it's a "WTF?" and members of the "WTF?" species are Bad. This being said, it's worth doing as if you were a student. Many surprises lie that way. > There is nothing sacred about the standard library any more. Oh yes there is. You are, of course, free to do away with it in your sandbox. But I'd get the assembly for the stuff before main() in an editor some time. > And, while > I am at it - I think <> includes should be abolished !!! > or, better, made > identical to "" includes. I'd rather see '"' includes done away with. > All the <> ever provided was the ability to > give short standard library file names by implying "look in the directory > where the standard library is." > No. See compiler option "-I <path>". MYODLALCA Make Yer Own Darn Language And Leave C Alone. :) ( 'C' is going to get incrementally harder to improve as time passes . ) -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-20 13:43 -0400 |
| Message-ID | <555CC7BE.1050209@verizon.net> |
| In reply to | #62356 |
On 05/20/2015 01:08 PM, Les Cargill wrote: > David Kleinecke wrote: ... >> Yes - I don't think there should be any reserved identifiers. ... >> Future conflicts between identifiers in the standard library can be >> handled in whatever fashion conflicts between identifiers in two pieces >> of user code are handled. That's no real change from the present standard. Conflicts between identifiers in two pieces of user code will often produce syntax errors or constraint violations, for which a diagnostic is required, but if neither of those apply, then the code will generally have undefined behavior for some other reason. If that's not the case, you can't legitimately describe it as a conflict. When a program declares or defines an identifier in a context where it is reserved, the program has undefined behavior, which is not significantly different. In principle, that rule gives the implementor the freedom to not generate the diagnostics that would ordinarily occur if the same type of conflict occurred between two pieces of user code. However, as a matter of QoI, I doubt that any implementation other than the DS9000 would do so - they'd have to go out of their way to disable such diagnostics.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-20 10:59 -0700 |
| Message-ID | <87y4kj1667.fsf@kst-u.example.com> |
| In reply to | #62356 |
Les Cargill <lcargill99@comcast.com> writes:
[...]
> You *CAN* reuse reserved identifiers by:
> - macro substitution.
> - the use of the "static" keyword
You cannot safely reuse identifiers starting with two underscores,
or with an underscore and an uppercase letter. They may be defined
by the standard library as macros, and a call to a standard library
function might use a macro that depends on such an identifier.
Perhaps you can be safe if you don't call any standard library
functions, or if you call them in a way that bypasses any macro
definition. Conceivably an implementation might even forbid or
ignore a #define that renames a reserved identifier, though I'm
not certain of the legality of doing so.
But since I can, with zero cost, simply avoid defining reserved
identifiers, I don't have to worry about it.
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-20 18:05 -0500 |
| Message-ID | <mjj3hi$6ij$1@dont-email.me> |
| In reply to | #62365 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: > [...] >> You *CAN* reuse reserved identifiers by: >> - macro substitution. >> - the use of the "static" keyword > > You cannot safely reuse identifiers starting with two underscores, > or with an underscore and an uppercase letter. Just to be clear, it's a terrible idea. But it's not difficult to do just about any sort of ... horrible thing with macros. > They may be defined > by the standard library as macros, and a call to a standard library > function might use a macro that depends on such an identifier. > It depends on where you do it. At the system build level, it'd be much more dangerous, but at the individual compilation/lexical unit you might get away with it. > Perhaps you can be safe if you don't call any standard library > functions, or if you call them in a way that bypasses any macro > definition. Conceivably an implementation might even forbid or > ignore a #define that renames a reserved identifier, though I'm > not certain of the legality of doing so. > I'd think that way lies madness, but it might be an interesting thing to try. > But since I can, with zero cost, simply avoid defining reserved > identifiers, I don't have to worry about it. > Indeed. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-20 17:36 -0700 |
| Message-ID | <87pp5u22cg.fsf@kst-u.example.com> |
| In reply to | #62373 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>>> You *CAN* reuse reserved identifiers by:
>>> - macro substitution.
>>> - the use of the "static" keyword
>>
>> You cannot safely reuse identifiers starting with two underscores,
>> or with an underscore and an uppercase letter.
>
> Just to be clear, it's a terrible idea. But it's not difficult to do
> just about any sort of ... horrible thing with macros.
>
>> They may be defined
>> by the standard library as macros, and a call to a standard library
>> function might use a macro that depends on such an identifier.
>>
>
> It depends on where you do it. At the system build level, it'd be much
> more dangerous, but at the individual compilation/lexical unit you
> might get away with it.
I'd say that "you might get away with it" is entirely consistent with
"You cannot safely ...".
[...]
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-20 22:12 -0500 |
| Message-ID | <mjji0o$bo9$2@dont-email.me> |
| In reply to | #62375 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: >> Keith Thompson wrote: >>> Les Cargill <lcargill99@comcast.com> writes: >>> [...] >>>> You *CAN* reuse reserved identifiers by: >>>> - macro substitution. >>>> - the use of the "static" keyword >>> >>> You cannot safely reuse identifiers starting with two underscores, >>> or with an underscore and an uppercase letter. >> >> Just to be clear, it's a terrible idea. But it's not difficult to do >> just about any sort of ... horrible thing with macros. >> >>> They may be defined >>> by the standard library as macros, and a call to a standard library >>> function might use a macro that depends on such an identifier. >>> >> >> It depends on where you do it. At the system build level, it'd be much >> more dangerous, but at the individual compilation/lexical unit you >> might get away with it. > > I'd say that "you might get away with it" is entirely consistent with > "You cannot safely ...". > > [...] > Violent agreement, sir. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-05-20 20:34 -0700 |
| Message-ID | <MPG.2fc6f2255108b2c627@news.eternal-september.org> |
| In reply to | #62375 |
Keith Thompson wrote: > Les Cargill writes: > > Keith Thompson wrote: > >> Les Cargill writes: > >>> You *CAN* reuse reserved identifiers by: > >>> - macro substitution. > >>> - the use of the "static" keyword > >> > >> You cannot safely reuse identifiers starting with two underscores, > >> or with an underscore and an uppercase letter. > > It depends on where you do it. At the system build level, it'd be > > much more dangerous, but at the individual compilation/lexical unit > > you might get away with it. > > I'd say that "you might get away with it" is entirely consistent with > "You cannot safely ...". Of course! There are an infinite number of reserved identifiers*, but only a finite number of them (that is, 0%) are actually used by any implementation. So your probability of conflicting with one is oh, I guess around 100%, depending on the influence of Murphy in your life. * Gcc, for example, has no limit on the length of identifiers.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-21 04:39 +0000 |
| Message-ID | <mjjnig$u47$1@speranza.aioe.org> |
| In reply to | #62380 |
Philip Lantz <prl@canterey.us> wrote: > Keith Thompson wrote: (snip) >> I'd say that "you might get away with it" is entirely consistent with >> "You cannot safely ...". > Of course! There are an infinite number of reserved identifiers*, but > only a finite number of them (that is, 0%) are actually used by any > implementation. So your probability of conflicting with one is oh, I > guess around 100%, depending on the influence of Murphy in your life. > * Gcc, for example, has no limit on the length of identifiers. Well, they probably have to be shorter than the size of your swap space. I do remember an ALGOL W compile from about 1970 with a 256 character limit. (When the input was on 80 column cards, or card images.) Compared to six for Fortran, that was pretty amazing. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-05-21 17:41 -0700 |
| Message-ID | <MPG.2fc81ae6b06cb1a127@news.eternal-september.org> |
| In reply to | #62385 |
glen herrmannsfeldt wrote: > Philip Lantz wrote: > > There are an infinite number of reserved identifiers*, but > > only a finite number of them (that is, 0%) are actually used by any > > implementation. So your probability of conflicting with one is oh, I > > guess around 100%, depending on the influence of Murphy in your life. > > > * Gcc, for example, has no limit on the length of identifiers. > > Well, they probably have to be shorter than the size of your swap space. The ones you use do, but the reserved ones don't.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2015-05-21 01:14 -0700 |
| Message-ID | <d4819c98-c069-4eef-931d-907151a7ec70@googlegroups.com> |
| In reply to | #62373 |
On Wednesday, May 20, 2015 at 11:59:11 PM UTC+1, Les Cargill wrote: > > Perhaps you can be safe if you don't call any standard library > > functions, or if you call them in a way that bypasses any macro > > definition. Conceivably an implementation might even forbid or > > ignore a #define that renames a reserved identifier, though I'm > > not certain of the legality of doing so. > > > > I'd think that way lies madness, but it might be an interesting > thing to try. There a few C++ "debugging guides" that suggest you can subvert class data-encapsulation with a strategic #define private public It's definitely question as to whether this should work, but there's no denying that it often does.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-21 09:26 -0700 |
| Message-ID | <d265f45e-8de1-4c52-9d08-b9c760e3d3e3@googlegroups.com> |
| In reply to | #62365 |
On Wednesday, May 20, 2015 at 10:59:36 AM UTC-7, Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
> [...]
> > You *CAN* reuse reserved identifiers by:
> > - macro substitution.
> > - the use of the "static" keyword
>
> You cannot safely reuse identifiers starting with two underscores,
> or with an underscore and an uppercase letter. They may be defined
> by the standard library as macros, and a call to a standard library
> function might use a macro that depends on such an identifier.
>
> Perhaps you can be safe if you don't call any standard library
> functions, or if you call them in a way that bypasses any macro
> definition. Conceivably an implementation might even forbid or
> ignore a #define that renames a reserved identifier, though I'm
> not certain of the legality of doing so.
>
> But since I can, with zero cost, simply avoid defining reserved
> identifiers, I don't have to worry about it.
>
I never personally advocated using leading underscores and I personally
never do (with a few carefully designed exceptions). I just quoted
somebody else's code that broke the underscore rules and remarked
that I didn't mind them doing that.
The specific example I offered was an version of statements like
typedef struct _GeditTab GeditTab;
in GTK+. But note where that "_G..." indentifier is.
In the C90 standard document this restriction on identifiers is part of
the Standard Library not the C language.
Perhaps the standard(s) need to explicitly allow free use of underscores
in identifiers which are struct/union tags and - for that matter struct
members as well. Even local variables appear to have no reason to be
restricted.
I don't care enough to mention this to the standard committee.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-21 10:33 -0700 |
| Message-ID | <87h9r5u97m.fsf@kst-u.example.com> |
| In reply to | #62414 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 20, 2015 at 10:59:36 AM UTC-7, Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>> > You *CAN* reuse reserved identifiers by:
>> > - macro substitution.
>> > - the use of the "static" keyword
>>
>> You cannot safely reuse identifiers starting with two underscores,
>> or with an underscore and an uppercase letter. They may be defined
>> by the standard library as macros, and a call to a standard library
>> function might use a macro that depends on such an identifier.
>>
>> Perhaps you can be safe if you don't call any standard library
>> functions, or if you call them in a way that bypasses any macro
>> definition. Conceivably an implementation might even forbid or
>> ignore a #define that renames a reserved identifier, though I'm
>> not certain of the legality of doing so.
>>
>> But since I can, with zero cost, simply avoid defining reserved
>> identifiers, I don't have to worry about it.
>
> I never personally advocated using leading underscores and I personally
> never do (with a few carefully designed exceptions). I just quoted
> somebody else's code that broke the underscore rules and remarked
> that I didn't mind them doing that.
Ok, nobody is requiring you to mind it, so I see no problem so far.
> The specific example I offered was an version of statements like
> typedef struct _GeditTab GeditTab;
> in GTK+. But note where that "_G..." indentifier is.
>
> In the C90 standard document this restriction on identifiers is part of
> the Standard Library not the C language.
It's part of the C standard. Section 7 of the C standard is no less
relevant than section 6, at least for hosted implementations.
> Perhaps the standard(s) need to explicitly allow free use of underscores
> in identifiers which are struct/union tags and - for that matter struct
> members as well. Even local variables appear to have no reason to be
> restricted.
There's a very good reason. Implementations may define such identifiers
*as macros*, either by defining them in a standard header file or by
predefining them in the compiler.
If an implementation predefines _GeditTab as the constant 42,
then the declaration
typedef struct _GeditTab GeditTab;
will fail to compile. GTK+ gets away with it because, apparently,
no implementations under which it's compiled happen to predefine
_GeditTab.
> I don't care enough to mention this to the standard committee.
--
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-22 09:42 -0700 |
| Message-ID | <5218fb08-39ea-4b78-9e14-5d946aade48c@googlegroups.com> |
| In reply to | #62418 |
On Thursday, May 21, 2015 at 10:33:24 AM UTC-7, Keith Thompson wrote: > > If an implementation predefines _GeditTab as the constant 42, > then the declaration > > typedef struct _GeditTab GeditTab; > > will fail to compile. GTK+ gets away with it because, apparently, > no implementations under which it's compiled happen to predefine > _GeditTab. I'm in a hurry today so I haven't checked. I was under the impression that struct tags are in a different name space than the body of the code and that predefining _GeditTab as 42 has no impact on using _GeditTab as a struct tab. Likewise struc/unuion members. In fact each struct/union is a separate small namespace of its own. Local variables are nor exposed outside the translation unit in which they are defined hence they are never seen by any other unit. Internally they should override any external definitions - like declarations in a block.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 11:53 -0700 |
| Message-ID | <878ucgsau6.fsf@kst-u.example.com> |
| In reply to | #62450 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, May 21, 2015 at 10:33:24 AM UTC-7, Keith Thompson wrote:
>> If an implementation predefines _GeditTab as the constant 42,
>> then the declaration
>>
>> typedef struct _GeditTab GeditTab;
>>
>> will fail to compile. GTK+ gets away with it because, apparently,
>> no implementations under which it's compiled happen to predefine
>> _GeditTab.
>
> I'm in a hurry today so I haven't checked. I was under the impression
> that struct tags are in a different name space than the body of the
> code and that predefining _GeditTab as 42 has no impact on using
> _GeditTab as a struct tab.
Yes, struct and union tags are in a different name space. But an
implementation may legally define _GeditTab *as a macro*. Macros are
not affected by name spaces.
[...]
--
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-23 10:01 -0700 |
| Message-ID | <7b99e2eb-6b33-4ad4-b4a6-647a44d1e181@googlegroups.com> |
| In reply to | #62462 |
On Friday, May 22, 2015 at 11:53:29 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Thursday, May 21, 2015 at 10:33:24 AM UTC-7, Keith Thompson wrote: > >> If an implementation predefines _GeditTab as the constant 42, > >> then the declaration > >> > >> typedef struct _GeditTab GeditTab; > >> > >> will fail to compile. GTK+ gets away with it because, apparently, > >> no implementations under which it's compiled happen to predefine > >> _GeditTab. > > > > I'm in a hurry today so I haven't checked. I was under the impression > > that struct tags are in a different name space than the body of the > > code and that predefining _GeditTab as 42 has no impact on using > > _GeditTab as a struct tab. > > Yes, struct and union tags are in a different name space. But an > implementation may legally define _GeditTab *as a macro*. Macros are > not affected by name spaces. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-23 14:53 -0700 |
| Message-ID | <87617jq7uk.fsf@kst-u.example.com> |
| In reply to | #62499 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, May 22, 2015 at 11:53:29 AM UTC-7, Keith Thompson wrote:
[...]
>> Yes, struct and union tags are in a different name space. But an
>> implementation may legally define _GeditTab *as a macro*. Macros are
>> not affected by name spaces.
>
> 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.
Incorrect. A C90 (or C99, or C11) implementation includes both the
compiler and the standard library. Standard headers are free to define
macros within the implementation's reserved name space. For example,
the implementation I'm using happens to have
#define _Mdouble_ double
in <math.h>. 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.)
> 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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-24 09:18 -0700 |
| Message-ID | <ef29524a-cc20-414d-8086-486801978f48@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:
> > On Friday, May 22, 2015 at 11:53:29 AM UTC-7, Keith Thompson wrote:
> [...]
> >> Yes, struct and union tags are in a different name space. But an
> >> implementation may legally define _GeditTab *as a macro*. Macros are
> >> not affected by name spaces.
> >
> > 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.
>
> Incorrect. A C90 (or C99, or C11) implementation includes both the
> compiler and the standard library.
Ah ha. We are using "implementation" in two different ways. To me
"implementation" means how the coding situation is realized. To
you it seems to mean something else. But anyway you and I said the
same thing:
translation unit ~ compiler
included in it ~ standard library
The last correspondence is a bit inexact because more things than the
standard library can be included.
The kind of thing that doesn't happen would be if an implementation
(my sense) were to automatically include some information (I assume
defines) at the start of every translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-24 13:13 -0700 |
| Message-ID | <87iobhpwdd.fsf@kst-u.example.com> |
| In reply to | #62532 |
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:
>> > On Friday, May 22, 2015 at 11:53:29 AM UTC-7, Keith Thompson wrote:
>> [...]
>> >> Yes, struct and union tags are in a different name space. But an
>> >> implementation may legally define _GeditTab *as a macro*. Macros are
>> >> not affected by name spaces.
>> >
>> > 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.
>>
>> Incorrect. A C90 (or C99, or C11) implementation includes both the
>> compiler and the standard library.
>
> Ah ha. We are using "implementation" in two different ways.
Apparently so. I'm using it correctly. By "correctly" I mean the
way it's defined by the ISO C standard, the document that defines
the language we discuss in this newsgroup.
If you insist on using terms defined by the standard with meanings
that are inconsistent with the way the standard defines them,
please choose different words, or at least make it very clear what
you mean. Otherwise I can only assume you're not interested in
communicating clearly.
> To me
> "implementation" means how the coding situation is realized.
I really don't know what that's supposed to mean. Can you clarify?
> To
> you it seems to mean something else. But anyway you and I said the
> same thing:
> translation unit ~ compiler
> included in it ~ standard library
> The last correspondence is a bit inexact because more things than the
> standard library can be included.
>
> The kind of thing that doesn't happen would be if an implementation
> (my sense) were to automatically include some information (I assume
> defines) at the start of every translation unit.
It can and does happen.
Several macro names are predefined by the compiler because the standard
requires them to be:
__DATE__
__FILE__
__LINE__
__STDC__
__STDC_HOSTED__
__STDC_VERSION__
__TIME__
(This list is from N1570 (C11) 6.10.8.1; they're not all defined by
C90.)
Compilers may and routinely do predefine other macros using reserved
identifiers. gcc, for example, predefines over 200 of them on
the system I'm using, all of them with names starting with "__".
They're all predefined by the compiler, independent of the library.
Run "gcc -E -dM" on any source file to see a list.
There is no coherent sense of the word "implementation" for which your
statement is correct.
--
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 09:38 -0700 |
| Message-ID | <741f37ba-ad92-41ea-b666-b17eaf3ef3ff@googlegroups.com> |
| In reply to | #62543 |
On Sunday, May 24, 2015 at 1:13:29 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > Ah ha. We are using "implementation" in two different ways. > > Apparently so. I'm using it correctly. By "correctly" I mean the > way it's defined by the ISO C standard, the document that defines > the language we discuss in this newsgroup. > > If you insist on using terms defined by the standard with meanings > that are inconsistent with the way the standard defines them, > please choose different words, or at least make it very clear what > you mean. Otherwise I can only assume you're not interested in > communicating clearly. > > > To me > > "implementation" means how the coding situation is realized. > > I really don't know what that's supposed to mean. Can you clarify? To quote the C90 standard (3.9) "implementation" means "A particular set of software running in a particular translaion environment ubder particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment." That's what I mean - or at least I think it means the same thing I mean. It's a particularly goofy way of saying it. I was unable to guess what you meant but it seemed different. I dunno about you but, like Hunpty-Dumpty, I am in charge of what I say - not the standard. My words are all meant as ordinary English words unless I sopecifically label them as technical or they only have technical meaning (eg "struct").
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-25 12:40 -0700 |
| Message-ID | <87fv6ko37f.fsf@kst-u.example.com> |
| In reply to | #62602 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, May 24, 2015 at 1:13:29 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > Ah ha. We are using "implementation" in two different ways.
>>
>> Apparently so. I'm using it correctly. By "correctly" I mean the
>> way it's defined by the ISO C standard, the document that defines
>> the language we discuss in this newsgroup.
>>
>> If you insist on using terms defined by the standard with meanings
>> that are inconsistent with the way the standard defines them,
>> please choose different words, or at least make it very clear what
>> you mean. Otherwise I can only assume you're not interested in
>> communicating clearly.
>>
>> > To me
>> > "implementation" means how the coding situation is realized.
>>
>> I really don't know what that's supposed to mean. Can you clarify?
>
> To quote the C90 standard (3.9) "implementation" means "A particular
> set of software running in a particular translaion environment ubder
> particular control options, that performs translation of programs for,
> and supports execution of functions in, a particular execution
> environment."
>
> That's what I mean - or at least I think it means the same thing I mean.
> It's a particularly goofy way of saying it.
>
> I was unable to guess what you meant but it seemed different.
I at least intended to use the definition of "implementation" specified
in the C standard. That definition has not changed significantly with
different editions of the standard.
The runtime library, specified in section 7 of the standard, is clearly
part of the "implementation". You seem to have been using it in a sense
that excludes the standard library. Did I misunderstand you?
> I dunno about you but, like Hunpty-Dumpty, I am in charge of what I say -
> not the standard. My words are all meant as ordinary English words
> unless I sopecifically label them as technical or they only have
> technical meaning (eg "struct").
I ask you what you mean by "implementation", and you cite the definition
given in the standard. Then you make this statement about Humpty Dumpty
(which is usually used as an example of how *not* to communicate
clearly). Do you see a contradiction there?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web