Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: pointers Date: Mon, 24 Oct 2016 12:20:32 -0700 Organization: None to speak of Lines: 94 Message-ID: References: <18d7b7b9-ea72-49d3-9535-df13d560473c@googlegroups.com> <726d78eb-47b3-1b92-0203-e2f63bb740ae@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="dc97ebc10d9ee65592f107439c98c97d"; logging-data="18800"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+F7cIHMz/2LvRZ6zI32qrd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ykgmxKAzSaNl0Vf7TEIqwUvBpus= sha1:GQLNmtvVFD3FO0xRdTN7iz+dxuQ= Xref: csiph.com comp.lang.c:95239 BartC writes: > On 24/10/2016 17:52, Keith Thompson wrote: >> BartC writes: >>> And yes I can see this being used, even if it's just to illustrate an >>> example like this (you'll need to imagine the spaces between &s): >>> >>> int **pointer; >>> >>> **pointer; // 3 net derefs (one is always implicit with >>> // variables in HLLs); result: int >>> &**pointer; // 2 net derefs; int* ( *pointer) >>> &&**pointer; // 1 net deref; int** ( pointer) >>> &&&**pointer; // 0 net derefs; int*** ( &pointer) >>> &&&&**pointer; // -1 net derefs: error (&&pointer) >> >> So the only reason you can think of to use those constructs is to >> illustrate them? That's hardly a good reason to add them to the >> language. >> >> The unary & operator yields the address of its operand. > > What does that mean? The operand must be an lvalue, which means it's an expression that designates an object. It yields the address of that object. (Or the operand can be a function designator, but that's not the case we're discussing.) > And how does it work with &**pointer? Exactly the same way it works for any other operand, except that the special case rule in 6.5.3.2p3 kicks in. What's the point of these questions? > Because **pointer would do a double dereference to get to the operand. > Are you saying now that the & operator effectively cancels that second > dereference? Does the word "now" imply that I'm saying something inconsistent with what I've said before? &**pointer is equivalent to *pointer, except that the constraints on the operators still apply and the result is not an lvalue. > If so, then & is behaving just as I suggested: removing a dereference, > while * adds one. (Rather than only giving the address of a named > operand with no intervening * ops.) > > Then there is no reason why & & can't remove both dereferences. Yes there is. The unary & operator doesn't just "remove a dereference". It yields the address of its operand, which must be an lvalue. > The resulting >> expression is not an lvalue, so another unary & cannot be applied to it. > > Why is **pointer an lvalue but not *pointer? Both **pointer and *pointer are lvalues. Where did you get the idea that *pointer isn't an lvalue? > **pointer is an an rvalue that can have & in front to yield the > equivalent of *pointer. > > *pointer is an rvalue that can have & in front to yield the equivalent > of pointer. > > But you can't have **pointer as an rvalue that can have & & in front to > yield the equivalent of pointer? That is, with the first & yielding > *pointer, and the second 'pointer'. I don't know what you mean by "rvalue". The standard doesn't use the term, but defines it in a footnote as the "value of an expression". *pointer and **pointer are both lvalues (assuming they're valid). The unary & operator requires an lvalue (or function designator, but we'll ignore that for now) as its operand. The resulting expression is not an lvalue. Therefore `& & pointer` is not valid; it's a constraint violation. The special case described in N1570 6.5.3.2p3 does not change that. If you don't believe that, then you're wrong. If you merely don't *like* it, then you're certainly entitled to that preference, but I have yet to see a valid basis for it. You seem to be inventing a principle that the unary * and & operators should cancel each other out when combined in arbitrary ways. There is no such principle in C. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"