Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8344 > unrolled thread
| Started by | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| First post | 2015-07-11 20:39 -0700 |
| Last post | 2015-09-16 10:17 -0700 |
| Articles | 20 on this page of 88 — 7 participants |
Back to article view | Back to alt.os.development
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-11 20:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-12 04:24 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 03:17 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 03:28 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:12 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 17:09 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-13 11:10 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:13 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-14 09:08 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:23 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:12 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:54 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-07 12:19 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-07 13:30 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:38 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:49 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 20:58 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 01:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-10 10:45 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 23:20 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:26 +0200
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:50 +0200
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-11 00:58 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 17:38 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-11 23:39 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 19:39 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:22 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:21 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-12 21:53 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:49 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:58 +0200
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 07:32 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:05 +0100
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 13:19 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-15 00:01 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 14:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-26 16:23 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2015-09-27 00:23 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-26 16:37 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:17 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:24 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:46 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:14 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-27 13:52 +0000
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:28 -0400
Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:31 +0000
Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 16:21 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-20 17:25 -0700
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:43 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:21 +0100
Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 13:02 +0200
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:09 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 13:32 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 18:51 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 18:16 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:36 -0700
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:56 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:45 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 10:28 +0100
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:53 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:17 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 16:54 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:39 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 20:31 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 09:03 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:48 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:33 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 23:17 +0100
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-20 17:37 -0400
Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-20 23:46 +0100
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 21:37 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 22:29 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 03:25 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:18 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:39 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:47 -0400
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:00 -0700
Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-13 09:15 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:45 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 10:55 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-15 19:23 -0700
Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-16 03:03 -0700
Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-16 10:17 -0700
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-27 10:17 -0400 |
| Message-ID | <op.x5mknqg2yfako5@localhost> |
| In reply to | #8848 |
On Sat, 26 Sep 2015 19:23:45 -0400, James Harris <james.harris.1@gmail.com> wrote: > On 26/09/2015 21:23, Rod Pemberton wrote: > Was this one of the C conversations you mysteriously stopped replying > to? If so then I have to say I can't see a point in responding. The same > might happen again. :-( > Says the guy who stops posting quite regulary for two to three weeks at a time ... So, I don't know why _you_ keep bringing up this issue, since you "disappear" so much. Also, Usenet is not IRC. AFAIK, I've got only one post on a.o.d, in this thread, remaining to read and respond to, which was posted by you, which I was slowly working through some code since you asked for sample code to demonstrate my position in your prior post. Although, I did have some problems with my newsreader when textnews when down and I had to use AIOE for a week and lost track of all posts I hadn't replied to. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-27 10:24 -0400 |
| Message-ID | <op.x5mkzuv4yfako5@localhost> |
| In reply to | #8850 |
On Sun, 27 Sep 2015 10:17:40 -0400, Rod Pemberton <boo@fasdfrewar.cdm> wrote: > On Sat, 26 Sep 2015 19:23:45 -0400, James Harris <james.harris.1@gmail.com> wrote: >> On 26/09/2015 21:23, Rod Pemberton wrote: >> Was this one of the C conversations you mysteriously stopped replying >> to? If so then I have to say I can't see a point in responding. The same >> might happen again. :-( >> > > Says the guy who stops posting quite regulary for two to three weeks at > a time ... So, I don't know why _you_ keep bringing up this issue, since > you "disappear" so much. Also, Usenet is not IRC. > > AFAIK, I've got only one post on a.o.d, in this thread, remaining to read > and respond to, which was posted by you, which I was slowly working through > some code since you asked for sample code to demonstrate my position in > your prior post. Correction: s/in this thread/in my C parser ramblings thread/ > Although, I did have some problems with my newsreader when textnews when > down and I had to use AIOE for a week and lost track of all posts I hadn't > replied to. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-27 10:46 -0400 |
| Message-ID | <op.x5mlzvluyfako5@localhost> |
| In reply to | #8850 |
On Sun, 27 Sep 2015 10:17:40 -0400, Rod Pemberton <boo@fasdfrewar.cdm> wrote: > On Sat, 26 Sep 2015 19:23:45 -0400, James Harris <james.harris.1@gmail.com> wrote: >> On 26/09/2015 21:23, Rod Pemberton wrote: >> Was this one of the C conversations you mysteriously stopped replying >> to? If so then I have to say I can't see a point in responding. The same >> might happen again. :-( >> > > Says the guy who stops posting quite regulary for two to three weeks at > a time ... So, I don't know why _you_ keep bringing up this issue, since > you "disappear" so much. Also, Usenet is not IRC. PS. I'm glad you haven't done the 5 year disappearing act of Alexei. :-D RP -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-01-16 16:14 +0000 |
| Message-ID | <n7dq47$f61$1@dont-email.me> |
| In reply to | #8850 |
On 27/09/2015 15:17, Rod Pemberton wrote: > On Sat, 26 Sep 2015 19:23:45 -0400, James Harris > <james.harris.1@gmail.com> wrote: >> Was this one of the C conversations you mysteriously stopped replying >> to? If so then I have to say I can't see a point in responding. The same >> might happen again. :-( >> > > Says the guy who stops posting quite regulary for two to three weeks at > a time ... So, I don't know why _you_ keep bringing up this issue, since > you "disappear" so much. Also, Usenet is not IRC. If I do "disappear" occasionally it's probably because of time pressures or, once, not having an internet connection. Frankly, I wondered if you backed out of discussions about C when you finally realised that H&S were misleading and that you were trying to defend was indefensible. In fact, the following seems to be the very discussion about C's switch that "you mysteriously stopped replying to" which I mentioned above: https://groups.google.com/forum/#!original/alt.os.development/NHO0s2rVE44/weLZWv5QapMJ I don't think you ever replied. There's no need to reply. I was just puzzled that you brought it up again after stopping replying on the same topic in the past. Also, see https://groups.google.com/forum/#!original/alt.os.development/NHO0s2rVE44/PRvIBRKKXcAJ wherein I asked you if you were going to reply but you didn't respond to that, either. I am happy to discuss it, if you want to. James
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-01-23 13:20 -0500 |
| Message-ID | <20160123132010.1ba9807f@_> |
| In reply to | #9095 |
On Sat, 16 Jan 2016 16:14:25 +0000 James Harris <james.harris.1@gmail.com> wrote: > On 27/09/2015 15:17, Rod Pemberton wrote: > > On Sat, 26 Sep 2015 19:23:45 -0400, James Harris > > <james.harris.1@gmail.com> wrote: > >> Was this one of the C conversations you mysteriously stopped > >> replying to? If so then I have to say I can't see a point in > >> responding. The same might happen again. :-( > >> > > > > Says the guy who stops posting quite regulary for two to three > > weeks at a time ... So, I don't know why _you_ keep bringing up > > this issue, since you "disappear" so much. Also, Usenet is not > > IRC. > > If I do "disappear" occasionally it's probably because of time > pressures or, once, not having an internet connection. > > Frankly, I wondered if you backed out of discussions about C when you > finally realised that H&S were misleading and that you were trying to > defend was indefensible. > > In fact, the following seems to be the very discussion about C's > switch that "you mysteriously stopped replying to" which I mentioned > above: > > [link] > > I don't think you ever replied. There's no need to reply. I was just > puzzled that you brought it up again after stopping replying on the > same topic in the past. > > Also, see > > [link] > > wherein I asked you if you were going to reply but you didn't respond > to that, either. > > I am happy to discuss it, if you want to. Ok, I've made a note of these. I'll have to go back and see what happened, but AIR there were a bunch on comp.lang.misc you didn't respond to either. I've got to a bunch of your posts today, but have more to go ... I recently dumped Opera as my newsreader because it would lose posts once the quantity of messages became larger. Also, reading from AIOE would mess it up. Sometimes, if someone hasn't responded in a long time, I may miss the indication that the thread had a new message. It's also possible I accidentally cleared it when clearing other threads I don't read. RP
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-01-27 13:52 +0000 |
| Message-ID | <n8aht9$7nq$1@dont-email.me> |
| In reply to | #9129 |
On 23/01/2016 18:20, Rod Pemberton wrote: > On Sat, 16 Jan 2016 16:14:25 +0000 > James Harris <james.harris.1@gmail.com> wrote: ... >> I am happy to discuss it, if you want to. > > Ok, I've made a note of these. I'll have to go back and see what > happened, but AIR there were a bunch on comp.lang.misc you didn't > respond to either. I've got to a bunch of your posts today, but > have more to go ... It is possible that I missed some c.l.m replies to you but by mistake. Once, when looking back at threads, I saw a post of yours wherein you asked me some questions. I felt bad when I noticed that it had no reply. But then I found that I had used your post to start a new thread - so had replied to the content even if not on the original thread. James
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-27 10:28 -0400 |
| Message-ID | <op.x5mk47nzyfako5@localhost> |
| In reply to | #8848 |
On Sat, 26 Sep 2015 19:23:45 -0400, James Harris <james.harris.1@gmail.com> wrote: > On 26/09/2015 21:23, Rod Pemberton wrote: >> On Fri, 18 Sep 2015 09:48:26 -0400, James Harris >> <james.harris.1@gmail.com> wrote: >>> In the previous case where we discussed H&S, i.e. in connection with the >>> switch statement, I found an online copy of their book and it seemed to >>> me that they had come across what they thought of were two different >>> forms (and were surprised at what they had found) so listed them without >>> realising how C worked. >> >> It seems as if you still don't accept it. >> >> Do you agree that Duff's device both exists and works? >> >> If so, then you must accept that H&S are correct here. > > [answer to question avoided] I already know what your position is from past threads. I'll continue as if you had directly stated you oppose their understanding or perspective, for which I don't believe I'm putting any words into your mouth or misstating your perspective. Tartan Laboratories produced C and Ada compilers for various platforms. "This book grew out of our work at Tartan Laboratories developing a family of C compilers, for a wide range of computers, from micros to supermainframes." from "C: A Reference manual", by Samuel P. Harbison and Guy L. Steele Jr., (C) 1991, 3rd ed., pg. vii Three key people who worked at Tartan are PHDs in computer science who specialized in language design, and were heavily involved in language implementation, design, and standardization. Steel and Harbison have been involved in standards process for ANSI C, C++, and Common LISP. Dr. William A. Wulf http://www.eecs.umich.edu/eecs/dow/wulf.html http://www.cs.virginia.edu/~wulf/resumes/resume.html Dr. Guy L. Steele, Jr. https://en.wikipedia.org/wiki/Guy_L._Steele,_Jr. Dr. Samuel P. Harbison, III http://www.harbison.org/sph3/ http://www.harbison.org/sph3/sph-cv-Feb11.htm So, let me get this straight, you, James Harris of ... somewhere in the U.K., have concluded that three PHDs in C.S., all of whon specialize in programming language design, who were involved in standardization of ANSI C, C++, and Common Lisp, whose book was reviewed by about 3 dozen other people, including PHDs from other universities, and other ANSI X3J11 contributors and renowned experts in C like P.J. Plauger, Henry Spencer, and Larry Rosler, have concluded that _they_ made a mistake? ... Although possible, that's highly improbable. I hope this call to authority as expressed here which is usually cited as a logical fallacy has thoroughly dispelled your notions. ;-) Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-01-16 16:31 +0000 |
| Message-ID | <n7dr44$j6c$1@dont-email.me> |
| In reply to | #8852 |
On 27/09/2015 15:28, Rod Pemberton wrote: > On Sat, 26 Sep 2015 19:23:45 -0400, James Harris > <james.harris.1@gmail.com> wrote: > >> On 26/09/2015 21:23, Rod Pemberton wrote: >>> On Fri, 18 Sep 2015 09:48:26 -0400, James Harris >>> <james.harris.1@gmail.com> wrote: > >>>> In the previous case where we discussed H&S, i.e. in connection with >>>> the >>>> switch statement, I found an online copy of their book and it seemed to >>>> me that they had come across what they thought of were two different >>>> forms (and were surprised at what they had found) so listed them >>>> without >>>> realising how C worked. >>> >>> It seems as if you still don't accept it. >>> >>> Do you agree that Duff's device both exists and works? >>> >>> If so, then you must accept that H&S are correct here. >> >> [answer to question avoided] > > I already know what your position is from past threads. I'll continue as > if you had directly stated you oppose their understanding or perspective, > for which I don't believe I'm putting any words into your mouth or > misstating your perspective. [Snipped various impressive credentials] > So, let me get this straight, you, James Harris of ... somewhere in the > U.K., > have concluded that three PHDs in C.S., all of whon specialize in > programming > language design, who were involved in standardization of ANSI C, C++, and > Common Lisp, whose book was reviewed by about 3 dozen other people, > including > PHDs from other universities, and other ANSI X3J11 contributors and > renowned > experts in C like P.J. Plauger, Henry Spencer, and Larry Rosler, have > concluded > that _they_ made a mistake? ... Although possible, that's highly > improbable. In reply to that: 1. I have never been a fan of asserting that because people have impressive qualifications that they are right. That is dangerous and borders on religious credulity. Issues of science can be discussed as issues using reasoning. It is unwise to defer to human 'higher powers' on things that we can out logically for ourselves. 2. Even the best among us makes mistakes. Even if H&S are wonderful and the best authors around they could also easily also err in one tiny detail. 3. Published and reviewed books can have mistakes - they can even be riddled with mistakes. IIRC there was a popular but infamous book by one of the Schilds which dissected the standard but was still riddled with mistakes due to a complete lack of understanding of C. 4. The reviewers could have seen the authors' misunderstanding and let it go if the book is aimed at beginners. The basic H&S message is not actually wrong, just misleading, and the fact that they came across it as they did shows their lack of understanding of one tiny part of C. > I hope this call to authority as expressed here which is usually cited as a > logical fallacy has thoroughly dispelled your notions. > > ;-) On the contrary. I am alarmed by your trust in certain people as demigods. ;-) James
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-01-23 13:20 -0500 |
| Message-ID | <20160123132019.30e9a23c@_> |
| In reply to | #9096 |
On Sat, 16 Jan 2016 16:31:26 +0000 James Harris <james.harris.1@gmail.com> wrote: > > I hope this call to authority as expressed here which is usually > > cited as a logical fallacy has thoroughly dispelled your notions. > > > > ;-) > > On the contrary. I am alarmed by your trust in certain people as > demigods. ;-) Ok. I think we'll have to leave the switch() issue on the "we simply don't agree" page for now ... RP
[toc] | [prev] | [next] | [standalone]
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-09-18 16:21 +0100 |
| Message-ID | <mtha30$2le$1@dont-email.me> |
| In reply to | #8804 |
"James Harris" <james.harris.1@gmail.com> wrote in message news:mt6dtq$dcc$1@dont-email.me... ... > int X1; /* External linkage */ > extern int X1; /* Copies the above */ > > extern int X2; /* External linkage */ > int X2; /* External linkage */ > > static int X3; /* Internal linkage */ > int X3; /* External linkage - conflict */ > > static int X4; /* Internal linkage */ > extern int X4; /* Copies the above */ > > extern int X5; /* External linkage */ > static int X5; /* Internal linkage - conflict */ > > Verified. GCC complained about X3 and X5 only. > > > void F1(void); /* == extern void F(void); */ > extern void F1(void); /* Copies the above */ > > extern void F2(void); > void F2(void); /* == extern void F(void); */ > > static void F3(void); /* Internal linkage */ > void F3(void); /* == extern ...; copies the above */ > > static void F4(void); > extern void F4(void); /* Copies the above */ > > void F5(void); /* == extern .... External linkage */ > static void F5(void); /* Internal linkage - conflict */ > > extern void F6(void); /* External linkage */ > static void F6(void); /* Internal linkage - conflict */ > > Verified. GCC complained about F5 and F6 only. > > > If someone else wants to try to explain the above feel free. Either > way, I will get back to it later. Based on <http://port70.net/~nsz/c/c89/c89-draft.html C89 draft. Section 3.1.2.2 Linkages of identifiers> here is my attempt to explain the rules as simply as possible. I have included the nomenclature of the standard but added other descriptions which I feel are easier to understand. Feel free to disagree with the new descriptions if they reflect a poor understanding but I have called them external linkage --> "public" internal linkage --> "private to a translation unit" no linkage --> "private to a function" In the standard other identifiers have no linkage but here we are just looking at objects defined within functions. I think the terms "public" and "private" are easier to understand but I have written both below. "extern" * If "extern" is applied to a second or subsequent declaration of an object or a function then use the linkage of the first declaration. * If "extern" is applied to the first declaration of an object or a function then the object or function has external linkage (i.e. is public). "static" * Within a function a "static" object has no linkage (i.e. is private to that function). * At file level "static" gives the object or function internal linkage (i.e. makes it private to that translation unit). unqualified * Within a function an unqualified object has no linkage (i.e. is private to that function). * At file level an unqualified *object* is given external linkage (i.e. is public) whereas an unqualified *function* is treated as if it was qualified as "extern". See above. In other words: "extern" is the copying qualification. It will copy the linkage of a previous declaration if one is in scope or, if the name is new, will declare it as external. "static" always means what it says. For unqualfied names see the detail above. If the above is right then why is it so complicated? Any suggestions? James
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2015-09-20 17:25 -0700 |
| Message-ID | <64609200-9fd1-47ef-b58b-907a5739336e@googlegroups.com> |
| In reply to | #8816 |
On Friday, September 18, 2015 at 8:21:57 AM UTC-7, James Harris wrote: > "James Harris" <...@gmail.com> wrote in message > news:mt6dtq$dcc$1@dont-email.me... > > ... > > > int X1; /* External linkage */ > > extern int X1; /* Copies the above */ > > > > extern int X2; /* External linkage */ > > int X2; /* External linkage */ > > > > static int X3; /* Internal linkage */ > > int X3; /* External linkage - conflict */ > > > > static int X4; /* Internal linkage */ > > extern int X4; /* Copies the above */ > > > > extern int X5; /* External linkage */ > > static int X5; /* Internal linkage - conflict */ > > > > Verified. GCC complained about X3 and X5 only. > > > > > > void F1(void); /* == extern void F(void); */ > > extern void F1(void); /* Copies the above */ > > > > extern void F2(void); > > void F2(void); /* == extern void F(void); */ > > > > static void F3(void); /* Internal linkage */ > > void F3(void); /* == extern ...; copies the above */ > > > > static void F4(void); > > extern void F4(void); /* Copies the above */ > > > > void F5(void); /* == extern .... External linkage */ > > static void F5(void); /* Internal linkage - conflict */ > > > > extern void F6(void); /* External linkage */ > > static void F6(void); /* Internal linkage - conflict */ > > > > Verified. GCC complained about F5 and F6 only. > > > > > > If someone else wants to try to explain the above feel free. Either > > way, I will get back to it later. > > Based on <http://port70.net/~nsz/c/c89/c89-draft.html C89 draft. Section > 3.1.2.2 > Linkages of identifiers> here is my attempt to explain the rules as > simply as possible. I have included the nomenclature of the standard but > added other descriptions which I feel are easier to understand. Feel > free to disagree with the new descriptions if they reflect a poor > understanding but I have called them > > external linkage --> "public" > internal linkage --> "private to a translation unit" > no linkage --> "private to a function" > > In the standard other identifiers have no linkage but here we are just > looking at objects defined within functions. > > I think the terms "public" and "private" are easier to understand but I > have written both below. > > > > "extern" > > * If "extern" is applied to a second or subsequent declaration of an > object or a function then use the linkage of the first declaration. > > * If "extern" is applied to the first declaration of an object or a > function then the object or function has external linkage (i.e. is > public). > > > "static" > > * Within a function a "static" object has no linkage (i.e. is private to > that function). > > * At file level "static" gives the object or function internal linkage > (i.e. makes it private to that translation unit). > > > unqualified > > * Within a function an unqualified object has no linkage (i.e. is > private to that function). > > * At file level an unqualified *object* is given external linkage (i.e. > is public) whereas an unqualified *function* is treated as if it was > qualified as "extern". See above. > > > > In other words: "extern" is the copying qualification. It will copy the > linkage of a previous declaration if one is in scope or, if the name is > new, will declare it as external. "static" always means what it says. > For unqualfied names see the detail above. That's about right (save the tiny details I might be missing as well). The inline specifier makes things even more "interesting". > If the above is right then why is it so complicated? Any suggestions? Rationale for International Standard--Programming Languages--C Revision 5.10 April-2003: ----8<---- 6.2.2 Linkages of identifiers The first declaration of an identifier, including implicit declarations before C99, must specify by the presence or absence of the keyword static whether the identifier has internal or external linkage. This requirement allows for one-pass compilation in an implementation which must treat internal linkage items differently from external linkage items. An example of such an implementation is one which produces intermediate assembler code, and which therefore must construct names for internal linkage items to circumvent identifier length and/or case restrictions in the target assembler. Pre-C89 practice in this area was inconsistent. Some implementations avoided the renaming problem simply by restricting internal linkage names by the same rules as the ones used for external linkage. Others have disallowed a static declaration followed later by a defining instance, even though such constructs are necessary to declare mutually recursive static functions. The requirements adopted in C89 called for changes in some existing programs, but allowed for maximum flexibility. ----8<---- As usual, there's history behind something odd in C. Alex
[toc] | [prev] | [next] | [standalone]
| From | "wolfgang kern" <nowhere@never.at> |
|---|---|
| Date | 2015-09-13 12:43 +0200 |
| Message-ID | <mt3l4t$6o5$1@speranza.aioe.org> |
| In reply to | #8765 |
Rod Pemberton wrote: >>> AIR, Wolfgang doesn't program in C, ... yet. ;-) >> You can be sure that I never ever will start coding in any HLL ! > So, you've never used a HLL? You've never even used BASIC or Pascal > or Fortran? How did you manage that? Usually school or work wants > you to use some HLL ... What if you design one? I used BASIC on C64 and ZX81 but soon changed to ASM and even this didn't satisfy my needs for freedom, so I started with machine code. My background is EE and Math, but HLL programming wasn't part of education at this time. Of course we heared about Cobol, Fortran and the like, but learned that this HLLs are made for non_technical people and we learned much more about Lord Logic. >>> He uses hex assembly. I'm glad to see he's learning a bit. >> Yeah, I learned that 'const' doesn't mean a 'constant'. > A 'static' variable doesn't mean 'constant' either and can change ... > If fact, 'static' has multiple meanings depending on where it's used. > If my old copy of Harbison & Steele is correct, it has four meanings. > Since I almost never use 'static', I had to look that up. I see a 'static variable' as one kept in memory until terminated. 'non-volatile' could be the other word for it ? > That's just one of many such situations with C. A quote or text > string is a string literal. A character is a character constant. > Like everything else in life, there is a "learning curve," which > means it takes some time and experience. > :-) >> I find it really interesting that a lot of misleading terms are >> widely used in all HLL, perhaps just meant to hide functionality >> from ignorant peepers like me :) > Haven't you ever needed another name or word for a subroutine > or label but were unable to think of one? There aren't any symbolic names in my code, because there is also no text-based source. > Sometimes, there are no useable names remaining. 'loop' is an > instruction. What other words are there for 'loop' in English? > There's 'loop'. That's it. British English has 'roundabout' > which is a type of backwards loop. C came up with 'for' 'while' > 'do' ... or perhaps borrowed them from other languages. 'repeat' > might work, but nothing accurately represents 'loop'. > I'd panic if I ever had to navigate this in England: > https://en.wikipedia.org/wiki/Magic_Roundabout_%28Swindon%29 I remember Roundabouts when I was in UK for vacation-update :) You have to drive on the left and turn around clockwise ! > I sometimes can't think of another appropriate name ... I'm > naming them 'stuff' and 'things' and 'whatever', like 'do_stuff' > 'fill_things' and 'emit_whatever'. Yes, I use completely vague > names so I'm not wasting time thinking of good names. Or, I > start labeling them with a letter and hex: l0000, l0001, ... > lffff. If I exceed the number for 'l' then it's 'm': m0000, > m0001, ... and so on. My code- and data-labels are just hex-figures and mean their address. __ wolfgang
[toc] | [prev] | [next] | [standalone]
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-09-13 09:21 +0100 |
| Message-ID | <mt3bjj$6pi$1@dont-email.me> |
| In reply to | #8764 |
"wolfgang kern" <nowhere@never.at> wrote in message news:mt1vt9$vqp$1@speranza.aioe.org... ... > Yeah, I learned that 'const' doesn't mean a 'constant'. Yes, in C it means "read only". > I find it really interesting that a lot of misleading terms are widely > used in all HLL, perhaps just meant to hide functionality from > ignorant peepers like me :) Yep, you can use "print" in Basic even without a printer attached. But then in assembly language are things much different? For example, you can write "mov" and all you get is a copy! James
[toc] | [prev] | [next] | [standalone]
| From | "wolfgang kern" <nowhere@never.at> |
|---|---|
| Date | 2015-09-13 13:02 +0200 |
| Message-ID | <mt3l4v$6o5$3@speranza.aioe.org> |
| In reply to | #8768 |
James Harris wrote: >> Yeah, I learned that 'const' doesn't mean a 'constant'. > Yes, in C it means "read only". >> I find it really interesting that a lot of misleading terms are widely >> used in all HLL, perhaps just meant to hide functionality from >> ignorant peepers like me :) > Yep, you can use "print" in Basic even without a printer attached. > But then in assembly language are things much different? Not too much, especially all the new SSE stuff needs explanation lookup aside memnonic and Opcode interpretation. > For example, you can write "mov" and all you get is a copy! :) Yes, and that's why my disassembler show either LD/ST (Zilog style) or "=" (in terse mode) instead. __ wolfgang
[toc] | [prev] | [next] | [standalone]
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-09-13 19:09 +0100 |
| Message-ID | <mt4e0e$7ch$1@dont-email.me> |
| In reply to | #8778 |
"wolfgang kern" <nowhere@never.at> wrote in message news:mt3l4v$6o5$3@speranza.aioe.org... ... >> For example, you can write "mov" and all you get is a copy! > > :) Yes, and that's why my disassembler show either LD/ST (Zilog style) > or "=" (in terse mode) instead. OT but I remember the Zilog Z80 as having the most appropriate mnemonic, i.e. LD. Everything was loaded (AIR) and that made sense to me. The term "load" does not imply move. I don't remember a store or ST mnemonic but maybe there was one on it or another Zilog CPU. James
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-11 13:32 -0700 |
| Message-ID | <msvds4$ig1$1@speranza.aioe.org> |
| In reply to | #8739 |
"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message
news:a9110bdf-add3-428c-b6da-2dbd52f45557@googlegroups.com...
>
> I don't know if it was the terminology that confused you or
> you rarely used const and volatile in those other places,
> where they can legally appear, but here's how it works.
> Let's go back to the very basics or close to them.
>
> Consider this declaration declaring multiple things:
>
> extern int a, *b, c[2], d(void), (*e)(void);
>
> What do we declare here actually?
>
> a: external int
> b: external pointer to int
> c: external array of 2 ints
> d: external function (taking nothing) returning int
> e: external pointer to function (taking nothing) returning int
>
> Agreed?
Agreed.
> All those types of b, c, d and e are derived types. They are
> derived from int by adding asterisks, parens, brackets and stuff
> like that. This int is the base type for a through e.
>
> In place of that int you could just as well have an enum or
> a struct (union):
>
> extern enum { EZERO } a, *b, c[2], d(void), (*e)(void);
> extern struct { int foo; } a, *b, c[2], d(void), (*e)(void);
>
> ParseBase() parses base types only: void, all these integer
> types (e.g. unsigned short int), enums and structs(union).
>
> It does not parse anything beyond the base type, at least,
> not by itself (it an be invoked recursively, though).
>
> All of the following parts are parsed in ParseDerived():
>
> a
> *b
> c[2]
> d(void)
> (*e)(void)
>
> Are you still with me?
Yes
> A little guide through the code of ParseDerived():
<snip code>
> Still with me?
yep.
> Now comes the most important part. You can have const and volatile
> in both the base type and in what comes after it and produces the
> derived type.
>
> Let me copy that example one more time so it's not lost:
>
> int * volatile * const * const volatile pppi;
>
> These consts and volatiles aren't redundant. Generally, it's not
> just a matter of taste of where to put them.
>
> What does the above declaration declare?
>
> Let's read it right to left:
>
> pppi: pointer (itself being const and volatile) to
> pointer (which is constant) to
> pointer (which is volatile) to
> int.
>
> You can also make that int (the base type) const and/or volatile:
>
> const volatile int * volatile * const * const volatile pppi;
>
> and in the base type part it is permitted to put these modifiers
> before or after the type they modify:
>
> int const volatile * volatile * const * const volatile pppi;
>
> Still with me?
This is where I am a bit fuzzy. It is probably because I haven't
used something like that, so never learned or researched it.
However, I believe with your explaination and a little more
reading and research, I will understand it.
Thanks. I learn something new every day. And here I thought
I was perfect, well nearly perfect :-)
> Well, then there, you have it. You have just been explained why
> incorporating support for const and volatile in ParseBase() only
> is insufficient.
>
> Agreed? Or was this still somehow confusing? If it was, ask.
Agreed. I will have to look over my code some more.
However, at the moment, and probably for some time, I will not
need anything like that in my OS development, and will probably
not pursue it much further than what I have done so far. At
least not at the moment. I will be interested to see what you
come up with, whenever you do add this functionality to yours.
Again, thanks for the work you have done, it has made my
work easier. I know I say this all the time and thank you
many times for it, but I am truly grateful for the efforts.
I have enjoyed and will continue to enjoy working on mine while
studying what you have done with yours.
Thanks,
Ben
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-09-11 18:51 -0400 |
| Message-ID | <op.x4tlsdpnyfako5@localhost> |
| In reply to | #8743 |
On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt <zfysz@fysnet.net> wrote: > However, at the moment, and probably for some time, I will not > need anything like that in my OS development, and will probably > not pursue it much further than what I have done so far. At > least not at the moment. I will be interested to see what you > come up with, whenever you do add this functionality to yours. Well, I rarely use any qualifiers. They're generally not needed, if you're a cautious programmer. I've never found a use for 'const'. I've only used 'static' once for convenience. 'volatile' is required once and a while for OS development, e.g., raw screen output or memory mapped device, especially for things outside the control of your code. 'register' was convenient. However, GCC eliminated the ability to use it for file scope variables. That, IMO, was the *PRIMARY* situation where you'd want to use one, e.g., fast global pointers or global counters for your application. Apparently, the GCC maintainers felt that Linux OS coders were abusing 'register' and this prevented registers from being used in OS code. 'register' variables can still be used within procedures, but an 'unsigned char' will typically use a register by default with the C compilers I'm accustomed to. Rod Pemberton -- Just how many texting and calendar apps does humanity need?
[toc] | [prev] | [next] | [standalone]
| From | "Benjamin David Lunt" <zfysz@fysnet.net> |
|---|---|
| Date | 2015-09-11 18:16 -0700 |
| Message-ID | <msvucu$kd0$1@speranza.aioe.org> |
| In reply to | #8746 |
"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
news:op.x4tlsdpnyfako5@localhost...
> On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt <zfysz@fysnet.net>
> wrote:
>
>> However, at the moment, and probably for some time, I will not
>> need anything like that in my OS development, and will probably
>> not pursue it much further than what I have done so far. At
>> least not at the moment. I will be interested to see what you
>> come up with, whenever you do add this functionality to yours.
>
> Well, I rarely use any qualifiers. They're generally not needed,
> if you're a cautious programmer. I've never found a use for 'const'.
> I've only used 'static' once for convenience. 'volatile' is required
> once and a while for OS development, e.g., raw screen output or
> memory mapped device, especially for things outside the control of
> your code. 'register' was convenient. However, GCC eliminated the
> ability to use it for file scope variables. That, IMO, was the
> *PRIMARY* situation where you'd want to use one, e.g., fast global
> pointers or global counters for your application. Apparently, the
> GCC maintainers felt that Linux OS coders were abusing 'register'
> and this prevented registers from being used in OS code. 'register'
> variables can still be used within procedures, but an 'unsigned char'
> will typically use a register by default with the C compilers I'm
> accustomed to.
I use 'const' on a regular basis. This helps me make sure not to
modify something that shouldn't be modified.
Ex:
int dosomething(const struct SOMESTRUCT *somestruct) {
// do something with the struct, but be sure
// to not modify any of it.
}
My compiler accounts for this. I think :-). Mostly anyway.
Alex has a point when he gave the example of the line that
needed to be derived.
int * volatile * const * const volatile pppi;
However, in my opinion, a compiler that will correctly compile
that line is a compiler way more advanced than the one I am
willing to work on, at least for the moment. I don't need
anything of that sort in my loader.sys file :-)
I think the next task I will do is to optimize some of the
output code.
For example, it currently outputs
mov eax,offset some_var
mov ebx,eax
mov eax,[ebx]
where it could easily be modified to output
mov ebx,offset some_var
mov eax,[ebx]
or even
mov eax,[some_var]
My code, Alex' code for that matter, does output
mov eax,[some_var]
for some statements, but also outputs
mov eax,offset some_var
mov ebx,eax
mov eax,[ebx]
for others.
Alex has done quite a bit of work on SmallerC. If you remember,
a while back, I asked about the 'case' statement within inner blocks:
switch (somevar) {
case 1:
for (;;) {
case 2:
...
}
break;
}
}
etc. Well he spent a while and created some code to make it work
which I adapted to my compiler.
You can tell Alex has spent some long nights working on his
project. :-)
I have some more studying to do to figure out all of the workings
of his compiler.
Anyway, thanks for the comments,
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some Assembly required.
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2015-09-12 02:36 -0700 |
| Message-ID | <d7f55944-15b0-4133-9e65-77579a8a4abe@googlegroups.com> |
| In reply to | #8749 |
On Friday, September 11, 2015 at 6:16:18 PM UTC-7, Benjamin David Lunt wrote:
...
> I think the next task I will do is to optimize some of the
> output code.
>
> For example, it currently outputs
>
> mov eax,offset some_var
> mov ebx,eax
> mov eax,[ebx]
>
> where it could easily be modified to output
>
> mov ebx,offset some_var
> mov eax,[ebx]
>
> or even
>
> mov eax,[some_var]
Right. I have already mentioned it here (either in response to you
or in response to Rod) that I have a mostly common code generator
for both "16-bit" code (= compiled to run in real or virtual 8086
mode) and 32-bit code. As you know, you have restrictions on which
registers you can use as address registers in 16-bit CPU modes.
So, this is why you can have sequences like:
instructions to calculate address in eax and then...
mov ebx, eax
mov eax, [ebx]
That's simply because I couldn't do
mov ax, [ax]
and had to use a move to bx:
mov bx, ax
mov ax, [bx]
And w.r.t. the following
> mov eax,offset some_var
> mov ebx,eax
> mov eax,[ebx]
I can say that (if I'm not mistaken) this is a typical sequence for
accessing element 0 of an array. The code generator receives
essentially "address of array + 0" and decides to perform the
addition in (e)ax, but the addition of 0 is eliminated as meaningless
and so you get the above sequence, which is far from perfect.
IOW, elimination of "+ 0" should occur early, but it occurs at
the point of emitting "add reg, 0", where it's too late.
> My code, Alex' code for that matter, does output
>
> mov eax,[some_var]
>
> for some statements, but also outputs
>
> mov eax,offset some_var
> mov ebx,eax
> mov eax,[ebx]
>
> for others.
>
> Alex has done quite a bit of work on SmallerC. If you remember,
> a while back, I asked about the 'case' statement within inner blocks:
>
> switch (somevar) {
> case 1:
> for (;;) {
> case 2:
> ...
> }
> break;
> }
> }
>
> etc. Well he spent a while and created some code to make it work
> which I adapted to my compiler.
>
> You can tell Alex has spent some long nights working on his
> project. :-)
Yeah, you can see the times of day (and night) worked on the compiler
on the Graphs/Punch card page of the project on Github. Those show
days of week and hours and dots represent commits on those days
at those hours. :)
> I have some more studying to do to figure out all of the workings
> of his compiler.
>
> Anyway, thanks for the comments,
¡Gracias por haber usarlo!
Alex
[toc] | [prev] | [next] | [standalone]
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-09-12 11:56 +0100 |
| Message-ID | <mt109k$kje$1@dont-email.me> |
| In reply to | #8746 |
"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message news:op.x4tlsdpnyfako5@localhost... > On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt > <zfysz@fysnet.net> wrote: > >> However, at the moment, and probably for some time, I will not >> need anything like that in my OS development, and will probably >> not pursue it much further than what I have done so far. At >> least not at the moment. I will be interested to see what you >> come up with, whenever you do add this functionality to yours. > > Well, I rarely use any qualifiers. They're generally not needed, > if you're a cautious programmer. I've never found a use for 'const'. I don't use it much but const is a good way to confirm that a certain piece of data is not updated in a function. Whether you are a cautious programmer or not, if you look at a certain function and wonder whether a variable, say, is updated anywhere in the function const can confirm it without you having to read through and understand the entire function (as long as it's not pointed at!). > I've only used 'static' once for convenience. C's static can be very useful in compartmentalising code. IIRC from discussions we've had before I know you don't favour data hiding so it's not surprising that it's not one you use much. In a function static says, essentially, to place the declaree in the data section (yet only visible in this function) rather than in the function's activation record. Outside a function static says to keep the declaree private and not share it with other source files. IME that can be useful for variables and functions. > 'volatile' is required > once and a while for OS development, e.g., raw screen output or > memory mapped device, especially for things outside the control of > your code. Yes. > 'register' was convenient. However, GCC eliminated the > ability to use it for file scope variables. That, IMO, was the > *PRIMARY* situation where you'd want to use one, e.g., fast global > pointers or global counters for your application. Apparently, the > GCC maintainers felt that Linux OS coders were abusing 'register' > and this prevented registers from being used in OS code. 'register' > variables can still be used within procedures, but an 'unsigned char' > will typically use a register by default with the C compilers I'm > accustomed to. I haven't used register for many years. It was useful once, when compilers were not smart enough to do sensible register allocation but it more often would get in the compiler's way now. The only use for it I can think of these days is to tell the compiler that a certain value must not have its address taken, and that doesn't seem very useful. James
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | alt.os.development
csiph-web