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 08:49:32 -0700 Organization: None to speak of Lines: 66 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="23225"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185kDNvAuo94EPU2RH284k5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:a2bwAV+glrw7znb+5ulfL+kP9aY= sha1:kWarALJeLVFEHSvHXqhG3qEYa0I= Xref: csiph.com comp.lang.c:95229 BartC writes: > On 24/10/2016 01:27, Keith Thompson wrote: >> BartC writes: >>> & & 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. > > The behaviour of the non-conforming compilers seems fine to be. Each & > and * pair cancel each other out, as seems to happen with the conforming > gcc. What compiler doesn't diagnose `& & &**pointer`? The standard clearly makes `& &pointer` a constraint violation. Part of a compiler's job is to diagnose errors. A compiler that fails to diagnose this particular error is not doing its job. One result of this failure would be that a programmer might use such a construct and not find out that it's invalid until the code is ported to a conforming compiler. > Should it matter then in which order the & and * appear? By the time you > get to the actual term, you've either got more & than *, or more * than > &, or they cancel each other out completely. The fact is that it *does* matter. The standard says that & and * cancel out in certain narrowly defined circumstances. I see no advantage in allowing them to cancel out in any cases beyond those defined by the standard. Is there some reason you'd want to write `& & &**pointer`, or that you care how the compiler handles it? > (Odd that it's the conforming gcc that allows && (without the space) as > address-of on labels. It seems to pick and choose what it wants to > conform to! But it does show that && (binary and) and && (unary > address-of-label) can co-exist.) I see nothing odd about it. gcc's unary `&&` operator is an extension. In standard C, `&&label` is a syntax error, and any conforming compiler (including `gcc -std=c11 -pedantic`) must diagnose it. Of course gcc is not a fully conforming compiler by default. -- 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"