Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: pointers
Date: Mon, 24 Oct 2016 09:52:25 -0700
Organization: None to speak of
Lines: 52
Message-ID: <lneg35bsfq.fsf@kst-u.example.com>
References: <eddd93ef-a47b-4400-9b0b-d936ffffe329@googlegroups.com> <nuikqj$sja$2@dont-email.me> <18d7b7b9-ea72-49d3-9535-df13d560473c@googlegroups.com> <726d78eb-47b3-1b92-0203-e2f63bb740ae@verizon.net> <nujilm$4tg$1@dont-email.me> <ln7f8yd20j.fsf@kst-u.example.com> <nukp62$tfg$1@dont-email.me> <lnpompbvcj.fsf@kst-u.example.com> <nulcl7$sr1$1@dont-email.me>
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="U2FsdGVkX18FOxDmw4TOONmzCKk+lqHC"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:6eoyeBCCXJ3vmiJ2w0sOc3fgYgk= sha1:ueKdE+/pvjUKIi9nq8nt0lyfqwg=
Xref: csiph.com comp.lang.c:95234

BartC <bc@freeuk.com> writes:
> On 24/10/2016 16:49, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> 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`?
>
> Pelles C and lccwin.
>
> And MSVC-2008.

So those compilers have a bug.  It happens.

[...]

> 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.  The resulting
expression is not an lvalue, so another unary & cannot be applied to it.
The special case rule in 6.5.3.2p3 doesn't change that (nor, IMHO,
should it).

Incidentally, that rule was added in C99.  It's not mentioned in the C99
Rationale, and I'm not sure why it was added.

> (You'll notice many of my posts strive to add orthogonality to C, but it 
> seems the language just won't have it!)

Orthogonality is nice, but I see no point in adding *gratuitious*
orthogonality that doesn't add any expressive power.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"