Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: pointers |
| Date | 2016-10-25 13:38 -0700 |
| Organization | None to speak of |
| Message-ID | <lnlgxc88q0.fsf@kst-u.example.com> (permalink) |
| References | (10 earlier) <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> |
BartC <bc@freeuk.com> writes:
[...]
> The 3000 from *pointer and the 3000 from &**pointer are the same value
> and the same type. Neither are the actual stored 3000, but a copy of
> it used as a transient rvalue existing somewhere in the workspace of
> the computer (registers, stack etc).
>
> One of these however can have & added in front, and the other can't.
>
> Why? Because *pointer is apparently an Lvalue, but &**pointer
> isn't. And why isn't it? Because it is Written. Not really very
> convincing...
>
> Actually I find your statements as to what is and what isn't an Lvalue
> confusing. I originally had LVALUE/NOT LVALUE above the other way
> around before I looked again at your posts.
The idea of an "lvalue" can be a bit confusing, particularly since the
standard went through two flawed definitions before settling on the
current one. And the standard's definition differs from the original
meaning.
Leaving aside the history, an lvalue is "an expression (with an object
type other than void) that potentially designates an object". (The word
"potentially" had to be added so that the lvalue-ness of an expression
can be determined at compile time.)
The name is inspired by the idea that an "lvalue" is something that can
appear on the left side of an assignment, though that doesn't cover all
cases. And note that designating an object is not the same as pointing
to an object. An lvalue can be the *name* of an object. It's a kind of
expression, not a value.
The unary "&" operator can only be applied to an lvalue; it yields the
address of an object, so its operand must designate an object (I'm
ignoring function designators). The value that results from the unary
"&" operator is an address that points to an object, but it's not the
name of an object, so it's not an lvalue.
The special case in N1570 6.5.3.2 that talks about `&*foo` not being
evaluated doesn't affect any of this, and it's not intended to. All the
constraints on the operands still apply, and the expression `&*foo` is
not an value -- because `&anything` is never an lvalue. That special
case was added to allow something like this:
int arr[10];
int *p;
for (p = &arr[0]; p <= &arr[10]; p ++) ...
to have defined behavior; see the recent discussion in comp.std.c.
The & and * operators are not simply inverses of each other than you can
use in pairs in any way you like.
> I've always thought passing a writeable Lvalue to functions often
> involved adding in a & to an expression. Now you say I have to leave
> out the & to get the Lvalue!
An expression passed to a function as an argument is never evaluated as
an lvalue. If it happens to be one, then the lvalue conversion
described in N1570 6.3.2.1p2 is applied to it. Function arguments are
passed by value.
You can of course pass `&foo` to a function if it's of the type the
function is expecting, or `foo` if that's what the function is
expecting.
>> Similarly, given:
>> int n = 25;
>> the expressions `n` and `25` yield the same value and the same type, but
>> only one of them designates an object.
>
> We're talking about things that might be reasonably be expected to
> have addresses; not numeric literals which usually don't.
>
>> 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?
>
> 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.
[...]
> 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.
--
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
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