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: Sun, 23 Oct 2016 17:27:56 -0700 Organization: None to speak of Lines: 53 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="7901"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19dHRHTGPC4fqpKg66+OBlU" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:mgQYTabS7euBrHiQhg0bLgRobik= sha1:DGlKxzbKL+iUpgfvkFNfRYa4Olk= Xref: csiph.com comp.lang.c:95218 BartC writes: > On 23/10/2016 18:58, James R. Kuyper wrote: >> On 10/23/2016 01:35 PM, asetofsymbols@gmail.com wrote: >>> I mean int *pointer, ***p; >>> p=&(&pointer); >>> What does it point p to? >> >> The parentheses are redundant, it's equivalent to & &pointer, which, as >> I've already said, is a constraint violation. Since &pointer is not an >> lvalue, it does not designate an object, violating 6.5.3.2p1. >> >> Let me expand on that explanation. &pointer is a pointer value which >> points at the pointer object named 'pointer'. This value does not have a >> corresponding C object that it need be stored in. That's why it's not an >> lvalue. [snip] > Why not just say that & &pointer is illegal? He did say that. Actually he said something more accurate, that it's a constraint violation. He also went on to explain why. I don't know why you'd object to that. > It is as meaningful as &25 (and I doubt many implementations will set up > a storage location containing 25 and return a pointer to that). > > & & is sometimes allowed like this: > > int **pointer; > > & & &**pointer; > > where the & & and ** cancel out. But gcc doesn't like it so it wouldn't > be wise to depend on it. No, that's not allowed (more precisely, it's still a constraint violation). N1570 6.5.3.2 says that &*foo is equivalent to foo "except that the constraints on the operators still apply and the result is not an lvalue". > For gcc, it needs to be written like this: > > &*&*&pointer; > > with the & and * interleaved. Because that's a different expression, which is not a constraint violation. The same applies to any conforming compiler. -- 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"