Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #95313

Re: pointers

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 Tue, 25 Oct 2016 15:39:19 -0700
Organization None to speak of
Lines 81
Message-ID <lnd1io8354.fsf@kst-u.example.com> (permalink)
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> <lneg35bsfq.fsf@kst-u.example.com> <nulfjf$qgb$1@dont-email.me> <ln60ohblkv.fsf@kst-u.example.com> <nulp42$nqg$1@dont-email.me> <lnshrla4et.fsf@kst-u.example.com> <num3c9$jso$1@dont-email.me> <lnlgxc88q0.fsf@kst-u.example.com> <nuol16$idr$1@dont-email.me>
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="U2FsdGVkX190e9STxJBuW96yhanGLq5c"
User-Agent Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock sha1:hgwn+OiV4OwYJ5tWLBBwsjU1kv0= sha1:NWLD+pbA8wsGVJjHAx8Goxc2bew=
Xref csiph.com comp.lang.c:95313

Show key headers only | View raw


BartC <bc@freeuk.com> writes:
> On 25/10/2016 21:38, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> No problem. I'm just intrigued. The language implementations I've done
>>> work differently, that's all. Here's some of the examples in my
>>> language (^ means dereference):
>> [snip]
>>
>> Um, I think your answer is (c), but it's hard to tell.  Of course other
>> languages are different; that's what makes them other languages.
>
> The language I gave examples in isn't that different; it's at the same 
> level as C and has to solve many of the same problems.

Can you please give a direct answer the question I asked upthread?

    Finally, I would seriously appreciate an answer to the following.
    Exactly what problem do you have with all this?  Do you (a)
    not believe me when I tell you what the standard actually says,
    or (b) not accept that the standard *means* what it says, or
    (c) simply dislike what the standard says?

> With the alternative approach to mixing & and *, the result is more 
> expressiveness, fewer problems and more useful diagnostics (so you get a 
> genuine error when the number of & or * is wrong for the type, not when 
> you hit some arbitrary restriction in the language).

I see nothing arbitrary about the restrictions.  & must be applied to an
lvalue, and does not yield an lvalue.  * may be applied either to a
non-lvalue or to an lvalue, and yields an lvalue.  (Again, ignoring
function designators.)  Both of those make perfectly good sense to me,
to the extent that I didn't have to refer to the standard to write this
paragraph (though I did check it to make sure).

I see no way that relaxing those rules would improve expressiveness.  I
can think of no *meaningful* expression that could be expressed with
looser rules that can't already be expressed (unless you want to add the
ability to implicitly create objects from expressions, thus allowing
things like &25).

> That C doesn't allow that expressiveness isn't a big deal as the terms 
> involved can usually be rewritten into something that's legal.

Not only legal, but clearer.  Given `int **ptr;`, you can't legally
write `& &*ptr`, but you can write `&ptr`.

> But it does seem rather unsatisfactory given that in other places C 
> /does/ allow any number of chained * ops which do not match the type of 
> the term they operate on. Example:
>
> f is a function with no associated pointers, but *f, **f, ***f are all 
> legal. As is &**f. But not & &**f which ought to be equivalent of f.)

Because a function designator is implicitly converted to the address
of the function in most contexts.  `& &**f` doesn't make sense,
because `&**f` is not an lvalue, so it doesn't designate anything
that has an address.  My solution is simple: it would never occur
to me to write `& &**f`, so I don't have to care what it might mean.

The special-case rule that allows collapsing `&*foo` to `foo` in some
restricted circumstances is intended to cover a quite narrow use case.
You're trying to extend it to use cases that don't really mean anything.
Shall I cite Emerson again?

>>> So there do appear to be advantages to doing things the way I've suggested.
>>
>> There's no point in discussing any advantages until we understand what
>> the standard currently says.
>
> The advantage is obvious. You don't need to explain why &*p is allowed 
> but not & &**p or *&p!

You're the only person I've had to explain that to.  And I'm still not
sure whether you don't understand the explanation or just don't like it.

-- 
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"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

pointers asetofsymbols@gmail.com - 2016-10-23 08:11 -0700
  Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 16:26 +0100
    Re: pointers asetofsymbols@gmail.com - 2016-10-23 10:35 -0700
      Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-23 17:47 +0000
        Re: pointers asetofsymbols@gmail.com - 2016-10-25 12:55 -0700
      Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 13:58 -0400
        Re: pointers BartC <bc@freeuk.com> - 2016-10-24 00:55 +0100
          Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-23 17:27 -0700
            Re: pointers BartC <bc@freeuk.com> - 2016-10-24 11:53 +0100
              Re: pointers supercat@casperkitty.com - 2016-10-24 07:29 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:55 -0700
                Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-24 14:02 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 14:42 -0700
                Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-25 08:56 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 12:17 -0700
                Re: pointers Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-26 06:37 -0700
              Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 08:49 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-24 17:25 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 09:52 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-24 18:15 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:20 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-24 20:58 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 13:16 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-24 23:53 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 13:38 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-25 23:06 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 15:39 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 00:26 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:44 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 01:02 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 17:35 -0700
                Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 06:27 +0000
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 12:47 +0100
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 09:05 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 18:46 +0100
                Re: pointers supercat@casperkitty.com - 2016-10-26 11:44 -0700
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:12 +0100
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 20:30 +0100
                Re: pointers supercat@casperkitty.com - 2016-10-26 13:02 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-26 11:52 -0700
                Re: pointers Ike Naar <ike@iceland.freeshell.org> - 2016-10-26 19:11 +0000
                Re: pointers BartC <bc@freeuk.com> - 2016-10-26 21:25 +0100
                Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 18:56 -0400
                Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-25 19:12 -0400
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-25 16:31 -0700
                Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-24 21:36 +0100
                Re: pointers BartC <bc@freeuk.com> - 2016-10-25 16:54 +0100
                Re: pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-25 19:09 +0100
                Re: pointers supercat@casperkitty.com - 2016-10-24 11:33 -0700
                Re: pointers Keith Thompson <kst-u@mib.org> - 2016-10-24 12:22 -0700
          Re: pointers James Kuyper <jameskuyper@verizon.net> - 2016-10-24 10:23 -0400
  Re: pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-23 12:31 -0400
    Re: pointers Richard Heathfield <rjh@cpax.org.uk> - 2016-10-23 17:38 +0100
  Re: pointers Lorinczy Zsigmond <zsiga@nospam.for.me> - 2016-10-24 14:02 +0200
  Re: pointers John Bode <jfbode1029@gmail.com> - 2016-10-24 13:34 -0700

csiph-web