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: Tue, 25 Oct 2016 17:35:35 -0700 Organization: None to speak of Lines: 48 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="2e7171af2bda6d09a7fcdc04643cbc45"; logging-data="10775"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0YvYm7hgyrcxXMmDLZCuC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:OEPEl5EF2dvBhbV74kQKP8DI22w= sha1:CRhrcOeNhhA9rIo9R4suCF02hE4= Xref: csiph.com comp.lang.c:95320 BartC writes: > On 26/10/2016 00:44, Keith Thompson wrote: >> BartC writes: >>> I don't think like that at all. I just use & either to get the address >>> of a storage location designated by an expression, or to offset a >>> pointer operation. I don't care what the standard says! >> >> I suggest that's why you have such difficulty understanding or accepting >> the actual rules. You think `& &*foo` makes some kind of sense, and you >> refuse to accept the reasonably straightforward reasons that it doesn't. > > Yet if the Standard had slightly different wording, then suddenly it > would make sense to you as well! But we'd be dealing with exactly the > same objects and operations. > >>> I'm not that bothered what language it is either. When you're dealing >>> with explicit pointers then the issues of applying address-of or >>> dereferencing pointers are universal. >> >> Not really. Applying address-of makes sense only when there's an object >> whose address you want. > > Well in your example of '& &*foo' I'd say that reduces to '&foo' due to > the &* cancelling each other. So we have the address of the object foo. > Perfectly reasonable. > > But the small-print in the C standard says that even though the &* in > &*foo cancels to result in just foo, you can't apply the second & to > '&*foo' as you can with 'foo' itself. > > You must see that it is the wording in that document that stops this > construct being legal, rather than anything wrong with the universal > ideas involved with this pointer and address manipulation. > > I think even Ben Bacarisse agreed with me that the Standard could easily > have had a somewhat different rule, where &* elimination was applied > recursively, that would have made & &*foo legal. You're wrong on several points. I will explain further if and only if you (1) answer the question I asked you before (the choices were (a), (b), and (c)) *and* (2) you directly ask me to explain. Or you can just continue to be wrong. -- 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"