Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 23 Oct 2012 16:39:05 -0500 From: Steve Thompson Newsgroups: comp.lang.c Subject: Re: Compatibility question Date: Tue, 23 Oct 2012 20:39:25 +0000 Organization: Friends of the Galactic Collective Message-ID: References: <0.a87a1c8a472d870b0466.20121022022701BST.87y5izxpne.fsf@bsb.me.uk> <0.d779297035d2edccd1b4.20121022173052BST.87ehkqbhab.fsf@bsb.me.uk> <2nYjPo.Krd.2aRbe@gmail.com> <0.5ef6d4d4944842791bc8.20121022210639BST.87pq4a9sq8.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: NN 6.4.3 Lines: 136 X-Trace: sv3-ycY49xET6c/T3OKo5m+DCvLoHqaZW4a+vz8iDWUF1tJG08axcJw8Z3UnDBBUw/EP343WNkGp7Cggius!JLp44iP09K4LI4tkG+7DDyWjSNHEhIAcEfOI7W/IHrf32FfhI6wgtZ1nzcTdZg== X-Complaints-To: www.supernews.com/docs/abuse.html X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 7174 X-Received-Bytes: 7315 Xref: csiph.com comp.lang.c:27606 On Tue, Oct 23, 2012 at 12:26:05PM -0700, Keith Thompson wrote: > Steve Thompson writes: > > On Mon, Oct 22, 2012 at 09:06:39PM +0100, Ben Bacarisse wrote: > [...] > >> Whatever goes on under the hood (and I'd dispute that 'a' is "really a > >> pointer") it's much easier to learn a language in its own terms, at > >> least as far as that's possible. > > > > Well, no. 'a' is never a pointer as such in the terms of the language > > syntax, but its treatment by the compiler internally is nominally > > equivalent to they way it handles a pointer, with the exception that > > the language grammar forbids its use in the program text as a pointer. > > I don't believe that's true. Do you have some evidence that it is? The distinction is largely moot. In a practical sense, all variables have a value which is stored somewhere. The compiler is making an explicit use of a pointer when it does something with the value. The problem is that "use" in this context may as well be referring to ether or memory and there's no easy way of knowing which it is. > > In a simplistic sense, all variables are pointers to a segment of > > program data, modifiable or otherwise. In the real world, variable > > values may move around in and from RAM to CPU registers and back while > > being identified as a single consistent entity. This helps to > > illustrate the difference between a language and its implementation. > > So a char object is really a pointer to char, an int object is > really a pointer to int, and a char** object is really a char**? No, a char ** object is a pointer to a char ** object. > I think you're simply adding an extra -- and unnecessary -- level > of indirection, and of confusion. > > There may also be some confusion between pointer *objects* and > pointer *values* (i.e., addresses). Let me say again that I am not talking about addresses as might be referenced in object code. Perhaps it will clarify that I am thinking of something like the phase space of the compiler as it is building the tree representing the source code of the program. > If I define an object of struct type and perform some operation > on it (say, a simple assignment), the generated code might very > well refer to the address of the object. There is no *object* > of pointer type, either explicitly or implicitly. That could depend on the way the compiler is designed. > Struct objects are very often manipulated via pointers (simulating > by-reference argument passing, for example), but that's a coding > convention, not anything inherent to the language. Agreed. > A struct object is a struct object, just as a scalar object is a > scalar object. The distinction you see between structs and scalars > doesn't exist. (Certainly there's a distinction, but it's not the > one you're talking about.) > > >> In C terms, 'a' names an object and 'a' is a (modifiable) lvalue > >> expression, just as if it had been declared to be an int. trying to > >> reconcile this with some model that says it's a pointer (when it isn't > >> one) is bound to be confusing. > > > > I was never happy with the term lvalue or rvalue. My brain wants to > > think in terms of pointers, variables, and values. Structures defined > > as automatic variables don't fit all that neatly in that classification. > > C's definitions of the terms lvalue and rvalue is not consistent with > their original meanings. > > Originally, an expression could be evaluated in two different ways, > depending on the context in which it appears. Given an assignment: > > int x = 42; > int y; > y = x; > > The expression `x` (on the right side of the assignment, thus > "rvalue") is evaluated *for its rvalue*, which is 42, whereas > the expresison `y` (on the left side, thus "lvalue" is evaluated > *for its lvalue*, which is the identify of the object named "y", > regardless of what value it happens to contain. (Either can be a > more complex expression, for example `arr[func(42)].member = abs(x) > + 42;`, so there can be some non-trivial computation involved in > determining an lvalue.) > > The C standard changed the meaning of "lvalue", so it refers to the > expression `y` itself, rather than to the result of evaluating it. > The standard doesn't use the term "rvalue" other than in a footnote, > which mentions in passing that an rvalue is the result of an > expression. > > See N1337 6.3.2.1. That does put it in perspective. > To oversimplify, an lvalue in C is an expression that designates > an object. Note carefully that *designating* an object needn't > involve generating a *pointer* to an object, or equivalently > computing the address of an object. A simple example: > > int x = 42; > register int y; > y = x; > > `y` is an lvalue, but it refers to an object that has no address. > The same thing happens if `y` is a bit field. > > Dropping the "register" keyword doesn't make any real conceptual > difference -- nor does making `x` and `y` structures rather than > scalars. See my comment above regarding the compiler's phase space, although I'm not quite sure that is the best term to use in describing what I am thinking. > You're right: "Structures defined as automatic variables don't fit > all that neatly in that classification" (of pointers, variables, > and values). The problem is not with the language, it's with your > way of thinking about it. I didn't say that the language is wrong; I think I was merely implying that bits of it are very confusing. Regards, Steve Thompson -- GOTO's are like guns. Safety is entirely contingent on the user.