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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-24 07:01 -0700 |
| Message-ID | <kfnzj4u6pne.fsf@x-alumni2.alumni.caltech.edu> |
| 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: >> 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. [snip] You are simply incorrect. They may, they can, and they do.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-24 09:58 -0700 |
| Message-ID | <69feb6fb-309a-4368-b411-77a2855b14e6@googlegroups.com> |
| In reply to | #62523 |
On Sunday, May 24, 2015 at 7:01:23 AM UTC-7, Tim Rentsch wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > At the C90 level an implementation can't define a macro. [snip] > > You are simply incorrect. They may, they can, and they do. As noted elsewhere - implementation seems to have different meanings.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-05-25 00:45 -0700 |
| Message-ID | <MPG.2fcc02957b1ba2f82a@news.eternal-september.org> |
| In reply to | #62535 |
David Kleinecke wrote: > > On Sunday, May 24, 2015 at 7:01:23 AM UTC-7, Tim Rentsch wrote: > > > David Kleinecke <dkleinecke@gmail.com> writes: > > > At the C90 level an implementation can't define a macro. [snip] > > > > You are simply incorrect. They may, they can, and they do. > > As noted elsewhere - implementation seems to have different > meanings. Regardless of your definition of implementation, this is true. Symbols are defined by the compiler, the preprocessor, and in headers (which you apparently don't consider to be part of the implementation).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 11:09 -0700 |
| Message-ID | <kfny4in51fw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62535 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Sunday, May 24, 2015 at 7:01:23 AM UTC-7, Tim Rentsch wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: >>> At the C90 level an implementation can't define a macro. [snip] >> >> You are simply incorrect. They may, they can, and they do. > > As noted elsewhere - implementation seems to have different > meanings. Apparently you have been using the term in a way that is different from how the Standard uses it, but that doesn't change the underlying facts.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-21 09:04 -0700 |
| Message-ID | <0c8d256a-990c-4813-9f2f-eeed9955f83a@googlegroups.com> |
| In reply to | #62356 |
On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote: > Make Yer Own Darn Language And Leave C Alone. :) > > ( 'C' is going to get incrementally harder to improve as > time passes . ) I prefer K&R C but not the commitment to a Unix environment. If I have any goals at all it is to the ultimate computer language. Meaning 3000 CE
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-21 10:36 -0700 |
| Message-ID | <87d21tu91s.fsf@kst-u.example.com> |
| In reply to | #62412 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote:
>> Make Yer Own Darn Language And Leave C Alone. :)
>>
>> ( 'C' is going to get incrementally harder to improve as
>> time passes . )
>
> I prefer K&R C but not the commitment to a Unix environment.
You prefer K&R C to C90? Do you find no value in function prototypes?
> If I have
> any goals at all it is to the ultimate computer language.
>
> Meaning 3000 CE
Does that refer to the year 3000? I'm less than optimistic that we'll
have an "ultimate computer language" by then.
--
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:56 -0700 |
| Message-ID | <e8382c6a-0cbd-443e-8110-0e4a4b8e61e0@googlegroups.com> |
| In reply to | #62421 |
On Thursday, May 21, 2015 at 10:36:54 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote: > >> Make Yer Own Darn Language And Leave C Alone. :) > >> > >> ( 'C' is going to get incrementally harder to improve as > >> time passes . ) > > > > I prefer K&R C but not the commitment to a Unix environment. > > You prefer K&R C to C90? Do you find no value in function prototypes? You are correct about function prototypes - that is an improvement on K&R. So is required function types and I suspect a few more details. K&R isn't perfect - just better. I am willing to accept section 6 of the C90 standard as core C - which is what I am talking about - unless I uncover a problem (which I have not so far). Assuming the standards have not changed structure - is there anything in the later standards that has changed or expanded section 6?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-22 12:16 -0500 |
| Message-ID | <qsouladmarilcnrpcjj0ngcnghleutjrm5@4ax.com> |
| In reply to | #62454 |
On Fri, 22 May 2015 09:56:22 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >On Thursday, May 21, 2015 at 10:36:54 AM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> > On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote: >> >> Make Yer Own Darn Language And Leave C Alone. :) >> >> >> >> ( 'C' is going to get incrementally harder to improve as >> >> time passes . ) >> > >> > I prefer K&R C but not the commitment to a Unix environment. >> >> You prefer K&R C to C90? Do you find no value in function prototypes? > >You are correct about function prototypes - that is an improvement on >K&R. So is required function types and I suspect a few more details. >K&R isn't perfect - just better. > >I am willing to accept section 6 of the C90 standard as core C - which >is what I am talking about - unless I uncover a problem (which I have >not so far). > >Assuming the standards have not changed structure - is there anything in >the later standards that has changed or expanded section 6? You mean structurally? Obviously the newer section 6's document many new (core) language features (VLAs, complex, restrict, etc.).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-22 14:14 -0400 |
| Message-ID | <555F7205.6070606@verizon.net> |
| In reply to | #62457 |
On 05/22/2015 01:16 PM, Robert Wessel wrote: > On Fri, 22 May 2015 09:56:22 -0700 (PDT), David Kleinecke > <dkleinecke@gmail.com> wrote: ... >> You are correct about function prototypes - that is an improvement on >> K&R. So is required function types and I suspect a few more details. >> K&R isn't perfect - just better. >> I am willing to accept section 6 of the C90 standard as core C - which >> is what I am talking about - unless I uncover a problem (which I have >> not so far). >> >> Assuming the standards have not changed structure - is there anything in >> the later standards that has changed or expanded section 6? Parts 6 and 7 of the Foreward to N1570.pdf list the changes made from previous versions of the standard. Almost all them had some effect on section 6, and I've listed those changes below. I've also identified the new keywords, since (particularly if you're restricting your attention to section 6) several of the key changes are more easily identified by those keywords than by the description in the Foreward. The following changes were made in C2011: ========================================= New keywords: — _Alignas — _Alignof — _Atomic — _Generic() — _Noreturn — _Static_assert — _Thread_local Other changes: — support for multiple threads of execution including an improved memory sequencing model — character constants and string literals of type char16_t, char32_t — string literals encoded in UTF-8 format. — anonymous structures and unions The following changes made in C99: ================================== New keywords: — inline — restrict — _Bool — _Complex — _Imaginary Other Changes: — more precise aliasing rules via effective type — variable length arrays — flexible array members — static and type qualifiers in parameter array declarators — the long long int type — remove implicit int — reliable integer division — universal character names (\u and \U) — extended identifiers — hexadecimal floating-point constants — compound literals — designated initializers — // comments — remove implicit function declaration — preprocessor arithmetic done in intmax_t/uintmax_t — mixed declarations and code — new block scopes for selection and iteration statements — integer constant type rules — integer promotion rules — macros with a variable number of arguments — IEC 60559 (also known as IEC 559 or IEEE arithmetic) support — trailing comma allowed in enum declaration — idempotent type qualifiers — empty macro arguments — new structure type compatibility rules (tag compatibility) — additional predefined macro names — _Pragma preprocessing operator — standard pragmas — _ _func_ _ predefined identifier — remove deprecation of aliased array parameters — conversion of array to pointer not limited to lvalues — relaxed constraints on aggregate and union initialization — relaxed restrictions on portable header names — return without expression not permitted in function that returns a value (and vice versa)
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-23 09:49 -0700 |
| Message-ID | <65274bb0-e979-426b-b216-8ae9e22fa5df@googlegroups.com> |
| In reply to | #62458 |
On Friday, May 22, 2015 at 11:14:43 AM UTC-7, James Kuyper wrote: > On 05/22/2015 01:16 PM, Robert Wessel wrote: > > On Fri, 22 May 2015 09:56:22 -0700 (PDT), David Kleinecke > > <dkleinecke@gmail.com> wrote: > ... > >> You are correct about function prototypes - that is an improvement on > >> K&R. So is required function types and I suspect a few more details. > >> K&R isn't perfect - just better. > >> I am willing to accept section 6 of the C90 standard as core C - which > >> is what I am talking about - unless I uncover a problem (which I have > >> not so far). > >> > >> Assuming the standards have not changed structure - is there anything in > >> the later standards that has changed or expanded section 6? > > Parts 6 and 7 of the Foreward to N1570.pdf list the changes made from > previous versions of the standard. Almost all them had some effect on > section 6, and I've listed those changes below. I've also identified the > new keywords, since (particularly if you're restricting your attention > to section 6) several of the key changes are more easily identified by > those keywords than by the description in the Foreward. > > The following changes were made in C2011: > ========================================= > New keywords: > -- _Alignas > -- _Alignof > -- _Atomic > -- _Generic() > -- _Noreturn > -- _Static_assert > -- _Thread_local > > Other changes: > -- support for multiple threads of execution including an improved memory > sequencing model > -- character constants and string literals of type char16_t, char32_t > -- string literals encoded in UTF-8 format. > -- anonymous structures and unions > > The following changes made in C99: > ================================== > New keywords: > -- inline > -- restrict > -- _Bool > -- _Complex > -- _Imaginary > > Other Changes: > -- more precise aliasing rules via effective type > -- variable length arrays > -- flexible array members > -- static and type qualifiers in parameter array declarators > -- the long long int type > -- remove implicit int > -- reliable integer division > -- universal character names (\u and \U) > -- extended identifiers > -- hexadecimal floating-point constants > -- compound literals > -- designated initializers > -- // comments > -- remove implicit function declaration > -- preprocessor arithmetic done in intmax_t/uintmax_t > -- mixed declarations and code > -- new block scopes for selection and iteration statements > -- integer constant type rules > -- integer promotion rules > -- macros with a variable number of arguments > -- IEC 60559 (also known as IEC 559 or IEEE arithmetic) support > -- trailing comma allowed in enum declaration > -- idempotent type qualifiers > -- empty macro arguments > -- new structure type compatibility rules (tag compatibility) > -- additional predefined macro names > -- _Pragma preprocessing operator > -- standard pragmas > -- _ _func_ _ predefined identifier > -- remove deprecation of aliased array parameters > -- conversion of array to pointer not limited to lvalues > -- relaxed constraints on aggregate and union initialization > -- relaxed restrictions on portable header names > -- return without expression not permitted in function that returns a > value (and vice versa) Thanks You. Now I know I will stick to C90. Call me a Luddite - I don't recognize any of these as improvements - except possibly _Bool (but I object to the underscore). I can see that C99 was the chief offender - just as I thought back in 2000. C11 just continues the trend. I see what has happened as a severe case of featuritis.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 11:55 -0700 |
| Message-ID | <874mn4sarb.fsf@kst-u.example.com> |
| In reply to | #62454 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, May 21, 2015 at 10:36:54 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote:
>> >> Make Yer Own Darn Language And Leave C Alone. :)
>> >>
>> >> ( 'C' is going to get incrementally harder to improve as
>> >> time passes . )
>> >
>> > I prefer K&R C but not the commitment to a Unix environment.
>>
>> You prefer K&R C to C90? Do you find no value in function prototypes?
>
> You are correct about function prototypes - that is an improvement on
> K&R. So is required function types and I suspect a few more details.
> K&R isn't perfect - just better.
>
> I am willing to accept section 6 of the C90 standard as core C - which
> is what I am talking about - unless I uncover a problem (which I have
> not so far).
>
> Assuming the standards have not changed structure - is there anything in
> the later standards that has changed or expanded section 6?
C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Each includes a foreword summarizing the changes from the previous
edition.
--
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-22 11:58 -0700 |
| Message-ID | <87zj4wqw0l.fsf@kst-u.example.com> |
| In reply to | #62454 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, May 21, 2015 at 10:36:54 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Wednesday, May 20, 2015 at 10:02:45 AM UTC-7, Les Cargill wrote:
>> >> Make Yer Own Darn Language And Leave C Alone. :)
>> >>
>> >> ( 'C' is going to get incrementally harder to improve as
>> >> time passes . )
>> >
>> > I prefer K&R C but not the commitment to a Unix environment.
>>
>> You prefer K&R C to C90? Do you find no value in function prototypes?
>
> You are correct about function prototypes - that is an improvement on
> K&R. So is required function types and I suspect a few more details.
> K&R isn't perfect - just better.
I'm not sure what you mean by "required function types". If you're
talking about the dropping of the implicit int rule, that didn't happen
until C99.
What features of C89/C90 that aren't in K&R C (as described in K&R1) do
you particularly dislike?
Personally, I find C90 to be pretty much unambiguously an improvement
over pre-ANSI K&R C. The fact that the language is more rigorously
defined reduced much of the need for massive nests of #ifdefs.
--
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-20 10:26 -0700 |
| Message-ID | <87bnhf2m96.fsf@kst-u.example.com> |
| In reply to | #62344 |
David Kleinecke <dkleinecke@gmail.com> writes:
> 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.
>
> If people have been obeying the rules so far there is no user code to
> break by abolishing identifier reservation.
>
> 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.
I.e., badly.
Frankly, I think that's foolish. Removing reserved identifiers would
have no benefit that I can see, and it would make it quite impossible to
write portable C code.
I'd like to see a *better* way of preventing and/or dealing with
conflicts among third-party libraries and user code. It's common for a
library to use a conventional prefix, which is an imperfect solution.
(POSIX doesn't follow any such convention, which means for example I can
write a function called "getline" if I only use standard C libraries,
but not if I use POSIX.)
Throwing out the one standard convention we have is not a solution.
(Personally, I'd like to see C++-style namespaces, but that's not the
only solution.)
If you can come up with a general and robust way to prevent name
conflicts, *then* it's worth considering applying it to the standard
library.
In the meantime, how difficult is it to avoid defining identifiers that
start with an underscore?
> There is nothing sacred about the standard library any more. And, while
> I am at it - I think <> includes should be abolished or, better, made
> identical to "" includes. 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."
Yes, that's basically what <> means. So with your suggestion, my
program that uses
#include <stdio.h>
which I suppose I'd have to change to
#include "stdio.h"
will break if someone writes a header with the same name.
Again, what benefit do we get from this change, and does that benefit
exceed the cost?
--
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-18 11:08 -0700 |
| Message-ID | <871tid69n5.fsf@kst-u.example.com> |
| In reply to | #62227 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, May 17, 2015 at 10:06:31 AM UTC-7, Richard Heathfield wrote:
[...]
>> You are mistaken. The naming rules /are/ part of the C language. See for
>> example 4.1.2 of C89 or Section 7.1.3 of C99 onwards.
>>
>> --
>> 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
David, please delete signatures from quoted material.
> In my copy of the C90 standard there is no 4.1.2. and Part 4 - entitled
> Compliance - does not discuss naming rules. I haven't looked at any later
> standard. If there are naming rules in C99 I am surprised and will take
> more care to mention version numbers.
The 1990 ISO C standard describes the same language as the 1989 ANSI C
standard. The differences are some introductory material mandated by
ISO, which caused some sections to be renumbered. In particular, ANSI
C89's sections 3 and 4 (describing the core language and the standard
library, respectively) became ISO C90's sections 6 and 7.
Richard could accurately have written "Section 7.1.3 of C90 onwards".
That section, "Reserved identifiers", specifies that:
- All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for
any use.
- All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary
identifier and tag name spaces.
That's unchanged in later editions of the standard.
--
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-19 10:09 -0700 |
| Message-ID | <09a0d259-93f9-4cb0-8fd5-ac0e1e0b32fc@googlegroups.com> |
| In reply to | #62233 |
On Monday, May 18, 2015 at 11:08:53 AM UTC-7, Keith Thompson wrote: > > David, please delete signatures from quoted material. Everywhere else I go they are automatically deleted. Oh Well. I usually do it anyway.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-18 20:40 +0100 |
| Message-ID | <mjdf5l$7ei$1@dont-email.me> |
| In reply to | #62227 |
On 18/05/15 18:38, David Kleinecke wrote: > On Sunday, May 17, 2015 at 10:06:31 AM UTC-7, Richard Heathfield wrote: >> On 17/05/15 17:40, David Kleinecke wrote: >> > On Sunday, May 17, 2015 at 3:51:21 AM UTC-7, Richard Bos wrote: >> >> David Kleinecke <dkleinecke@gmail.com> wrote: >> >> >> >> > On Wednesday, May 6, 2015 at 11:35:01 PM UTC-7, Richard Heathfield wrote: >> >> > > On 07/05/15 07:08, asetofsymbols@gmail.com wrote: >> >> > > > But names that begin with _ are >> >> > > > not reserved to compiler? >> >> > > >> >> > > Not all of them, but by far the best course is to avoid declaring any >> >> > > identifiers beginning with an underscore. That way, you /know/ you >> >> > > aren't breaking any rules. >> >> > > >> >> > > Although you have provided no context and haven't started your subject >> >> > > line with "Re:", I guess you're actually responding to someone else's >> >> > > article, in which they have used underscores to begin identifiers. This >> >> > > may be because they don't know the rules, but it may be because they are >> >> > > sketching out code that a compiler writer might use in, say, a library >> >> > > function. Without context, it isn't possible to say which. >> >> >> >> > It's the style used in GTK+ (I used a cut-and-paste from gedit in fact >> >> > under the impression that gedit should be considered part of GTK+) >> >> >> >> If GTK+ is meant to be part of the implementation, that's allowed. If >> >> it's meant to be treated as a normal user library, it's not. >> >> (Some identifiers starting with _ are allowed in some circumstances, but >> >> the code in question used _ followed by a capital letter, which is >> >> reserved for the implementation in all cases. And anyway, it's better to >> >> err on the safe side, usually.) >> >> >> > You have set of rules you imagine I should follow. I don't think they >> > are part of the C language. >> >> You are mistaken. The naming rules /are/ part of the C language. See for >> example 4.1.2 of C89 or Section 7.1.3 of C99 onwards. >> > > In my copy of the C90 standard there is no 4.1.2. Right. That's why I said C89. Section numbering was the major change from C89 to C90. > and Part 4 - entitled > Compliance - does not discuss naming rules. Perhaps you should look more closely. Look, for example, for text such as "All external identifiers declared in any of the headers are reserved, whether or not the associated header is included. All external identifiers that begin with an underscore are reserved. All other identifiers that begin with an underscore and either an upper-case letter or another underscore are reserved. If the program defines an external identifier with the same name as a reserved external identifier, even in a semantically equivalent form, the behavior is undefined." > I haven't looked at any later > standard. If there are naming rules in C99 I am surprised and will take > more care to mention version numbers. Then I may safely deduce that you are surprised, and will take more care to mention version numbers. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-17 14:34 -0400 |
| Message-ID | <mjamt6$sm3$1@dont-email.me> |
| In reply to | #62177 |
On 05/17/2015 12:40 PM, David Kleinecke wrote: > On Sunday, May 17, 2015 at 3:51:21 AM UTC-7, Richard Bos wrote: ... >> If GTK+ is meant to be part of the implementation, that's allowed. If >> it's meant to be treated as a normal user library, it's not. >> (Some identifiers starting with _ are allowed in some circumstances, but >> the code in question used _ followed by a capital letter, which is >> reserved for the implementation in all cases. And anyway, it's better to >> err on the safe side, usually.) >> >> Richard > > You have set of rules you imagine I should follow. ... Whether or not you follow them is up to you. If you wish your code to have defined behavior, you should follow them. If you don't care what your program does, then you should feel free to ignore them. > ... I don't think they > are part of the C language. Technically, you're correct, but I reach that conclusion only by being pedantic: those rules are not part of the C language, they merely describe requirements for correct use of that language. They are part of the C standard. Specifically, section 7.1.3: > 1 Each header declares or defines all identifiers listed in its associated subclause, and > optionally declares or defines identifiers listed in its associated future library directions > subclause and identifiers which are always reserved either for any use or for use as file > scope identifiers. > — All identifiers that begin with an underscore and either an uppercase letter or another > underscore are always reserved for any use. > — All identifiers that begin with an underscore are always reserved for use as identifiers > with file scope in both the ordinary and tag name spaces. > — Each macro name in any of the following subclauses (including the future library > directions) is reserved for use as specified if any of its associated headers is included; > unless explicitly stated otherwise (see 7.1.4). > — All identifiers with external linkage in any of the following subclauses (including the > future library directions) and errno are always reserved for use as identifiers with > external linkage.184) > — Each identifier with file scope listed in any of the following subclauses (including the > future library directions) is reserved for use as a macro name and as an identifier with > file scope in the same name space if any of its associated headers is included. > > 2 No other identifiers are reserved. If the program declares or defines an identifier in a > context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved > identifier as a macro name, the behavior is undefined. Note, in particular, those last three words. The reason why some identifiers are reserved is so that implementations can use them for their own purposes. The reason the behavior is undefined, is that if the implementation does use of one those identifiers for some purpose, and a developer tries to use the same identifier for a conflicting purpose, something is likely to go wrong. This clause gives implementations permission to let those things go wrong. Such code would not be strictly conforming, and if something does go wrong, the author is at fault. It works the other way, too. Identifiers that are NOT reserved to the implementation are identifiers that you are free to use in your own code. If an implementation uses an identifier in a context where it is NOT reserved, and a developer uses the same name for a conflicting purpose, something is likely to go wrong. Such an implementation would be non-conforming, and if something does go wrong, the implementor is at fault. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-18 10:40 -0700 |
| Message-ID | <26959c5d-196b-4743-b4c8-dfa6db565f19@googlegroups.com> |
| In reply to | #62193 |
On Sunday, May 17, 2015 at 11:34:25 AM UTC-7, James Kuyper wrote: > On 05/17/2015 12:40 PM, David Kleinecke wrote: > > On Sunday, May 17, 2015 at 3:51:21 AM UTC-7, Richard Bos wrote: > ... > >> If GTK+ is meant to be part of the implementation, that's allowed. If > >> it's meant to be treated as a normal user library, it's not. > >> (Some identifiers starting with _ are allowed in some circumstances, but > >> the code in question used _ followed by a capital letter, which is > >> reserved for the implementation in all cases. And anyway, it's better to > >> err on the safe side, usually.) > >> > >> Richard > > > > You have set of rules you imagine I should follow. ... > > Whether or not you follow them is up to you. If you wish your code to > have defined behavior, you should follow them. If you don't care what > your program does, then you should feel free to ignore them. > > > ... I don't think they > > are part of the C language. > > Technically, you're correct, but I reach that conclusion only by being > pedantic: those rules are not part of the C language, they merely > describe requirements for correct use of that language. They are part of > the C standard. Specifically, section 7.1.3: > > > 1 Each header declares or defines all identifiers listed in its associated subclause, and > > optionally declares or defines identifiers listed in its associated future library directions > > subclause and identifiers which are always reserved either for any use or for use as file > > scope identifiers. > > -- All identifiers that begin with an underscore and either an uppercase letter or another > > underscore are always reserved for any use. > > -- All identifiers that begin with an underscore are always reserved for use as identifiers > > with file scope in both the ordinary and tag name spaces. > > -- Each macro name in any of the following subclauses (including the future library > > directions) is reserved for use as specified if any of its associated headers is included; > > unless explicitly stated otherwise (see 7.1.4). > > -- All identifiers with external linkage in any of the following subclauses (including the > > future library directions) and errno are always reserved for use as identifiers with > > external linkage.184) > > -- Each identifier with file scope listed in any of the following subclauses (including the > > future library directions) is reserved for use as a macro name and as an identifier with > > file scope in the same name space if any of its associated headers is included. > > > > 2 No other identifiers are reserved. If the program declares or defines an identifier in a > > context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved > > identifier as a macro name, the behavior is undefined. > > Note, in particular, those last three words. > > The reason why some identifiers are reserved is so that implementations > can use them for their own purposes. The reason the behavior is > undefined, is that if the implementation does use of one those > identifiers for some purpose, and a developer tries to use the same > identifier for a conflicting purpose, something is likely to go wrong. > This clause gives implementations permission to let those things go > wrong. Such code would not be strictly conforming, and if something does > go wrong, the author is at fault. > > It works the other way, too. Identifiers that are NOT reserved to the > implementation are identifiers that you are free to use in your own > code. If an implementation uses an identifier in a context where it is > NOT reserved, and a developer uses the same name for a conflicting > purpose, something is likely to go wrong. Such an implementation would > be non-conforming, and if something does go wrong, the implementor is at > fault. > -- > James Kuyper Once again I will have to insure that everyone is aware that I do not accept these "improvements" over C90.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-18 11:18 -0700 |
| Message-ID | <87siat4uml.fsf@kst-u.example.com> |
| In reply to | #62228 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, May 17, 2015 at 11:34:25 AM UTC-7, James Kuyper wrote:
[...]
>> The reason why some identifiers are reserved is so that implementations
>> can use them for their own purposes. The reason the behavior is
>> undefined, is that if the implementation does use of one those
>> identifiers for some purpose, and a developer tries to use the same
>> identifier for a conflicting purpose, something is likely to go wrong.
>> This clause gives implementations permission to let those things go
>> wrong. Such code would not be strictly conforming, and if something does
>> go wrong, the author is at fault.
>>
>> It works the other way, too. Identifiers that are NOT reserved to the
>> implementation are identifiers that you are free to use in your own
>> code. If an implementation uses an identifier in a context where it is
>> NOT reserved, and a developer uses the same name for a conflicting
>> purpose, something is likely to go wrong. Such an implementation would
>> be non-conforming, and if something does go wrong, the implementor is at
>> fault.
>
> Once again I will have to insure that everyone is aware that I do not
> accept these "improvements" over C90.
Of course they're not improvements of C90 -- because they're already
in C90.
The rules for reserved identifiers are essentially unchanged across
C89, C90, C99, and C11. (The "Future library directions" section
has grown a bit with the addition of new headers.)
Can you clarify what features you dislike? 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?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-05-18 14:33 -0400 |
| Message-ID | <555A306E.9010201@verizon.net> |
| In reply to | #62228 |
On 05/18/2015 01:40 PM, David Kleinecke wrote: > On Sunday, May 17, 2015 at 11:34:25 AM UTC-7, James Kuyper wrote: ... >> ... those rules ... are part of >> the C standard. Specifically, section 7.1.3: >> >>> 1 Each header declares or defines all identifiers listed in its associated subclause, and >>> optionally declares or defines identifiers listed in its associated future library directions >>> subclause and identifiers which are always reserved either for any use or for use as file >>> scope identifiers. >>> -- All identifiers that begin with an underscore and either an uppercase letter or another >>> underscore are always reserved for any use. >>> -- All identifiers that begin with an underscore are always reserved for use as identifiers >>> with file scope in both the ordinary and tag name spaces. >>> -- Each macro name in any of the following subclauses (including the future library >>> directions) is reserved for use as specified if any of its associated headers is included; >>> unless explicitly stated otherwise (see 7.1.4). >>> -- All identifiers with external linkage in any of the following subclauses (including the >>> future library directions) and errno are always reserved for use as identifiers with >>> external linkage.184) >>> -- Each identifier with file scope listed in any of the following subclauses (including the >>> future library directions) is reserved for use as a macro name and as an identifier with >>> file scope in the same name space if any of its associated headers is included. >>> >>> 2 No other identifiers are reserved. If the program declares or defines an identifier in a >>> context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved >>> identifier as a macro name, the behavior is undefined. >> >> Note, in particular, those last three words. >> >> The reason why some identifiers are reserved is so that implementations >> can use them for their own purposes. The reason the behavior is >> undefined, is that if the implementation does use of one those >> identifiers for some purpose, and a developer tries to use the same >> identifier for a conflicting purpose, something is likely to go wrong. >> This clause gives implementations permission to let those things go >> wrong. Such code would not be strictly conforming, and if something does >> go wrong, the author is at fault. >> >> It works the other way, too. Identifiers that are NOT reserved to the >> implementation are identifiers that you are free to use in your own >> code. If an implementation uses an identifier in a context where it is >> NOT reserved, and a developer uses the same name for a conflicting >> purpose, something is likely to go wrong. Such an implementation would >> be non-conforming, and if something does go wrong, the implementor is at >> fault. ... > Once again I will have to insure that everyone is aware that I do not <nit-pick> insure->assure </nit-pick> > accept these "improvements" over C90. They are not "improvements over C90" - the relevant requirements date back to C89, though there may have been minor modifications to them that I'm not aware of. Do you disapprove of the purpose of these requirements, as I've explained it? I assure you that almost all C implementations that I've ever heard of take heavy advantage of these rules. Specifically: If an implementation of the C standard library defines any identifier with external linkage that is not specified by the C standard (and most of them define quite a few), it will give it a reserved name, guaranteeing that it will conflict with a user-defined identifier only if the user's code violates 7.1.3. If one of the standard headers #defines a macro that is not specified by the C standard (and most of them #define quite a few), it will be given a name that is "reserved for any use", so that it will conflict with a user-defined identifiers only if the user's code violates 7.1.3. If any of the standard headers uses an identifier internally (such as the variable names of an static function definition, or of a function-like macro, it will be given a name that is "reserved for any use", so that user-#defined macros won't break the standard header unless the user's code violates 7.1.3. If 7.1.3 were repealed in the next version of the standard, how would you recommend implementors deal with those issues? I strongly suspect that most would simply choose not to implement that version, but if you can suggest sufficiently simple work-arounds, that might not be the case.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web