473,323 Members | 1,570 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,323 software developers and data experts.

Help with pointer discussion

mdh
Hi,
Could someone help clarify something on page 99 of K&R II.
It says if "pa is a pointer, expressions my use it with a subscript;
pa[i] is identical to *(pa +i)."
Here is what is confusing to me. I assume that pa[i] points to the
address of the "i th " element of an object ( array I assume). But,
then will not *(pa +i) dereference the "i th " element and refer to
the contents not the address?
Obviously I am wrong, but I would like to understand why?
thanks as usual.

Feb 11 '07 #1
22 1538
In article <11**********************@k78g2000cwa.googlegroups .com>,
mdh <md**@comcast.netwrote:
>Could someone help clarify something on page 99 of K&R II.
It says if "pa is a pointer, expressions my use it with a subscript;
pa[i] is identical to *(pa +i)."
Here is what is confusing to me. I assume that pa[i] points to the
address of the "i th " element of an object ( array I assume). But,
then will not *(pa +i) dereference the "i th " element and refer to
the contents not the address?
When pa[i] appears on the "right hand side" of an assignment
expression, pa[i] refers to the contents, not to the address, just
as is the case for *(pa + i) .

When pa[i] appears on the "left hand side" of an assignment
operator, such as pa[i] = 7; then pa[i] refers to the address of
the element as the destination for the assignment, just as is
the case for *(pa+i) in the same context.

These two are the same as each other:

x = pa[i] + 5;
x = *(pa+i) + 5

These two are the same as each other:

pa[i] = x + 5;
*(pa+i) = x + 5;

but in the first group, pa[i] and *(pa+i) refer to content, and
in the second group, pa[i] and *(pa+i) tell the compiler which location
to put the value into.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Feb 11 '07 #2
mdh wrote:
Hi,
Could someone help clarify something on page 99 of K&R II.
It says if "pa is a pointer, expressions my use it with a subscript;
pa[i] is identical to *(pa +i)."
Here is what is confusing to me. I assume that pa[i] points to the
address of the "i th " element of an object ( array I assume). But,
then will not *(pa +i) dereference the "i th " element and refer to
the contents not the address?
Obviously I am wrong, but I would like to understand why?
thanks as usual.
Your error is that pa[i] is an object, not its address. It is (pa + i)
that points to the object and *(pa + i) is the object itself.

Read it again, this time from page 97.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Feb 11 '07 #3
mdh writes:
Could someone help clarify something on page 99 of K&R II.
It says if "pa is a pointer, expressions my use it with a subscript;
pa[i] is identical to *(pa +i)."
And when they these are identical, they mean it. Try this:

int foo(int i, int pa[]) { return i[pa]; }

After all that's just *(i + pa) - which is the same as *(pa + i).
They could of course have imposed the restriction that the expression
in front of '[]' must be a pointer, but either they forgot it when
they defined the language or they just didn't bother.

--
Regards,
Hallvard
Feb 11 '07 #4
mdh
On Feb 11, 11:06 am, Joe Wright <joewwri...@comcast.netwrote:
mdh wrote:
It says if "pa is a pointer, expressions my use it with a subscript;
pa[i] is identical to *(pa +i)."
>Joe Wright wrote:
Your error is that pa[i] is an object, not its address. It is (pa + i)
that points to the object and *(pa + i) is the object itself.

Read it again, this time from page 97.

Well, I really do try and do the work before I post a question. If you
look at my questions since starting C, you have never seen my post
something like..." A friend asked me to help him write a function
that ......etc etc. Please send code to my professor!!!" :-)

Anyway, levity aside, let me pursue this a little further. On page 98
of K&R II, the telling line to me is this one. pa is a pointer.
Then, if pa points to a[0], then *(pa+1) refers to the contents of
a[1], pa+1 is the address of a[i], and *(pa + i) is the contents of
a[i]. I follow this perfectly, I think. The other definition that is
relevant, I thnk, is that the value of type array is the address of
element zero, so pa = a ( an array). All of this follows logically,
which is what I like about C.
So, now back to the original question.
All one is told is that pa is a pointer. From the first line in the
chapter, ( a pointer is a variable that contains the address of a
variable) I would be able to understand the logic that pa[i] would be
equivalent to (pa+i) ( the address of a[i]). I know a lot of poster
have said that this is not so, and I do not question it, I am just
trying to see where the logic of my comprehension is failing.

Feb 11 '07 #5
mdh wrote:

All one is told is that pa is a pointer. From the first line in the
chapter, ( a pointer is a variable that contains the address of a
variable) I would be able to understand the logic that pa[i] would be
equivalent to (pa+i) ( the address of a[i]). I know a lot of poster
have said that this is not so, and I do not question it, I am just
trying to see where the logic of my comprehension is failing.

But that's wrong. pa[i] is NOT equivalent to pa+i, it's conceptually an
accessor to the VALUE contained at that array location. If pa is a
pointer to int, then pa[i] is an int.

pa[i] is exactly equivalent to *(pa+i). That's why you can do the old
trick i[pa], where that's the same as pa[i].

That is:

pa[i] == *(pa+i) == *(i+pa) == i[pa]


Brian
Feb 11 '07 #6
mdh wrote:
>
Anyway, levity aside, let me pursue this a little further. On page 98
of K&R II, the telling line to me is this one. pa is a pointer.
Then, if pa points to a[0], then *(pa+1) refers to the contents of
a[1], pa+1 is the address of a[i], and *(pa + i) is the contents of
a[i]. I follow this perfectly, I think. The other definition that is
relevant, I thnk, is that the value of type array is the address of
element zero, so pa = a ( an array). All of this follows logically,
which is what I like about C.
So, now back to the original question.
All one is told is that pa is a pointer. From the first line in the
chapter, ( a pointer is a variable that contains the address of a
variable) I would be able to understand the logic that pa[i] would be
equivalent to (pa+i) ( the address of a[i]). I know a lot of poster
have said that this is not so, and I do not question it, I am just
trying to see where the logic of my comprehension is failing.
Perhaps what you are missing is that [] is an operator
(some other languages do not treat their analogous array-indexing
constructs as operators, but C does). In C, it is an operator
with two operands: the thing before the [] and the thing inside.
The operation that this operator performs has two aspects: it
adds an integer and a pointer (the two operands) to produce a
new pointer value, and it "dereferences" (follows) that new
value to access the thing it points at.

The two separate operations are more clearly visible in
the equivalent form `*(pa + i)': you can see the addition and
you can see the dereference. The fact that you can't see them
in `pa[i]' (or in `i[pa]', which is mostly just a curiosity)
doesn't mean they aren't there.

Why does C have this rather strange two-things-at-once
operator? Because it's convenient. Programmers use arrays a
lot, and it's nice to have a concise way to get at their elements.
The [] operator isn't strictly necessary -- one could spend one's
life writing *(pa + i) -- but [] makes things less tiresome.

Also, when you get to two-dimensional arrays (C doesn't
really have them, but it does have one-dimensional arrays whose
elements can also be one-dimensional arrays), you will see that
the [] is much more convenient. Which would you prefer: x[i][j]
or *(*(x+i)+j)?

Hope this helps.

--
Eric Sosman
es*****@acm-dot-org.invalid

Feb 11 '07 #7
mdh
On Feb 11, 3:08 pm, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>
Perhaps what you are missing is that [] is an operator....... In C, it is an operator
with two operands: .............: it adds an integer and a pointer (the two operands) to produce a
new pointer value, and it "dereferences" (follows) that new
value to access the thing it points at.


Aha...yes that does make a lot more sense.This is the first time I
have seen it expressed like that. Perhaps that is still coming later
in K&R.
>
The two separate operations are more clearly visible in
the equivalent form `*(pa + i)': you can see the addition and
you can see the dereference. The fact that you can't see them
in `pa[i]' (or in `i[pa]', which is mostly just a curiosity)
doesn't mean they aren't there.

........ one could spend one's
life writing *(pa + i) -- but [] makes things less tiresome.
>
Hope this helps.
Eric, thanks. That does help a lot. The thing that threw me was the
fact that pa was named as a pointer. Earlier in the chapter, he
deduces the relationship of a[i] and *(pa+i) where a is an integer
array. But, if I understand you correctly, the [] operand, implies
both additon/subtraction of the pointer AND derefencing it.Not
understanding the dereferencing part is/was my source of confusion.

Thanks for taking the time to answer.

Feb 12 '07 #8
"mdh" <md**@comcast.netwrites:
[...]
Eric, thanks. That does help a lot. The thing that threw me was the
fact that pa was named as a pointer. Earlier in the chapter, he
deduces the relationship of a[i] and *(pa+i) where a is an integer
array. But, if I understand you correctly, the [] operand, implies
both additon/subtraction of the pointer AND derefencing it.Not
understanding the dereferencing part is/was my source of confusion.
Yes, that's right.

If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 12 '07 #9
mdh


mdh opined:
>>But, if I understand you correctly, the [] operand, implies
both additon/subtraction of the pointer AND derefencing it.Not
understanding the dereferencing part is/was my source of confusion.
On Feb 11, 7:05 pm, Keith Thompson <k...@mib.orgwrote:
>
Yes, that's right.

If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

thanks Keith and Eric and others who replied. Makes a lot more sense
now.

Feb 12 '07 #10
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).
It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .

Suppose
a[i] = 5;
a[i] = 7;
a[i+1] = a[i] * 6;

If one speaks of the a[i] on the left hand side of the
first and second statement as implying dereferencing in the same way
that a[i] does in the right hand side of the third statement,
then one starts getting into thinking that the second statement
replaces the value 5 with the value 7, not just at the location
a[i] but -everywhere- in the rest of the program. Used on the left
hand side of an assignment, a[i] and *(a+i) can only be understood
in terms of denoting a -location- -- but the a[i] in the third
statement can only be understood in terms of delivering a -value-.
And yet the same operator is being used for the two.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
Feb 12 '07 #11
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .
[...]

Good point. I'm not certain whether the term "dereference" is
appropriate in that case. (The standard uses the word "dereferencing"
only once, and that's in a footnote.)

It's the same situation as the unary "*" operator. Here's what the
standard says:

The unary * operator denotes indirection. If the operand points to
a function, the result is a function designator; if it points to
an object, the result is an lvalue designating the object. If the
operand has type "pointer to _type_", the result has type
"_type_". If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 12 '07 #12
Keith Thompson wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .
[...]

Good point. I'm not certain whether the term "dereference" is
appropriate in that case. (The standard uses the word "dereferencing"
only once, and that's in a footnote.)
I think that the term dereference is perfectly applicable, conceptually. But
more so to connotate the area which will be assigned to which also has the
same type. Similar to the same way: size_t r; int *p = NULL; r = sizeof *p;
is not really dereferencing p.
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
Suppose
a[i] = 5;
a[i] = 7;
a[i+1] = a[i] * 6;

If one speaks of the a[i] on the left hand side of the
first and second statement as implying dereferencing in the same way
that a[i] does in the right hand side of the third statement,
then one starts getting into thinking that the second statement
replaces the value 5 with the value 7, not just at the location
a[i] but -everywhere- in the rest of the program. Used on the left
hand side of an assignment, a[i] and *(a+i) can only be understood
in terms of denoting a -location- -- but the a[i] in the third
statement can only be understood in terms of delivering a -value-.
And yet the same operator is being used for the two.
I think the issue here is more so with lvalue vs rvalue and how those play out
rather than the [] operator itself. Ironically, sizeof *p, in the example
above, is not an lvalue nor is it actually dereferencing the contents.
Keith's point about the unary operator is probably what's most important.
Although does the language at the end apply to sizeof?

If the operand has type "pointer to _type_", the result has type
"_type_". If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined.

int *p = (int *)rand(); sizeof *p;

Will the sizeof work on the deathstation 9k? It's got to, or everyone doing p
= malloc(sizeof *p); would be setting off nuclear bombs.
Feb 12 '07 #13
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .
OK, but I think it is confusing to talk about something being "used as
an lvalue". a[i] *is* an lvalue -- the wording about * says it is.
Suppose
a[i] = 5;
a[i] = 7;
a[i+1] = a[i] * 6;

If one speaks of the a[i] on the left hand side of the
first and second statement as implying dereferencing in the same way
that a[i] does in the right hand side of the third statement,
then one starts getting into thinking that the second statement
replaces the value 5 with the value 7, not just at the location
a[i] but -everywhere- in the rest of the program.
I don't see how this is different to

ai = 5;
ai = 7;
aipo = ai * 6;

Because ai denotes an lvalue it can be used in places where non-l
values can't be. Of course lvalues are normally converted into the
value stored in the object denoted by the lvalue (as in the case of ai
in line 3) and this conversion does not happen when an lvalue is used
as an operand of certain operators, but I think is would be confusing
to call this conversion "deference".

Looked at it this way, the left hand side of an assignment prevents
this conversion from lvalue to stored value (in all cases -- plain
variables, array elements etc) but the "dereference" (the conversion
from pointer to lvalue) is always there in expressions like a[i]. It
makes for a simpler way of looking at it.

--
Ben.
Feb 12 '07 #14
In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:
>Of course lvalues are normally converted into the
value stored in the object denoted by the lvalue (as in the case of ai
in line 3) and this conversion does not happen when an lvalue is used
as an operand of certain operators, but I think is would be confusing
to call this conversion "deference".
In Algol 68, a[i] (an array element) and ai (a simple variable of
the same integer type) would have the same 'mode', both being
ref integer (if I recall correctly.) Algol then defines circumstances
under which a ref integer is automatically dereferenced .

It does make sense to think of a[i] and *(a+i) and ai as all
producing locations, and that in some contexts locations are
automatically dereferenced to get at the value, and in other
contexts, locations (i.e., addresses) are copied, and in other
contexts, locations are used as the target in which to store values.
We aren't used to thinking of it that way in C; it was quite explicit
in Algol 68.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
Feb 12 '07 #15
Christopher Layne wrote:
Keith Thompson wrote:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .
[...]

Good point. I'm not certain whether the term "dereference" is
appropriate in that case. (The standard uses the word "dereferencing"
only once, and that's in a footnote.)

I think that the term dereference is perfectly applicable, conceptually. But
more so to connotate the area which will be assigned to which also has the
same type. Similar to the same way: size_t r; int *p = NULL; r = sizeof *p;
is not really dereferencing p.
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
Suppose
a[i] = 5;
a[i] = 7;
a[i+1] = a[i] * 6;

If one speaks of the a[i] on the left hand side of the
first and second statement as implying dereferencing in the same way
that a[i] does in the right hand side of the third statement,
then one starts getting into thinking that the second statement
replaces the value 5 with the value 7, not just at the location
a[i] but -everywhere- in the rest of the program. Used on the left
hand side of an assignment, a[i] and *(a+i) can only be understood
in terms of denoting a -location- -- but the a[i] in the third
statement can only be understood in terms of delivering a -value-.
And yet the same operator is being used for the two.

I think the issue here is more so with lvalue vs rvalue and how those play out
rather than the [] operator itself. Ironically, sizeof *p, in the example
above, is not an lvalue nor is it actually dereferencing the contents.
Keith's point about the unary operator is probably what's most important.
Although does the language at the end apply to sizeof?

If the operand has type "pointer to _type_", the result has type
"_type_". If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined.

int *p = (int *)rand(); sizeof *p;

Will the sizeof work on the deathstation 9k? It's got to, or everyone doing p
= malloc(sizeof *p); would be setting off nuclear bombs.
Provided the conversion of rand's result does not result in a trap
representation, the sizeof also works. sizeof's argument is not
evaluated, and the behaviour is only undefined if the * operator is
evaluated. Otherwise, you couldn't even do

if (p != NULL)
*p = 5;

Feb 12 '07 #16
"mdh" <md**@comcast.netwrote in message
news:11*********************@k78g2000cwa.googlegro ups.com...
Anyway, levity aside, let me pursue this a little further. On page 98
of K&R II, the telling line to me is this one. pa is a pointer.
Then, if pa points to a[0], then *(pa+1) refers to the contents of
a[1], pa+1 is the address of a[i], and *(pa + i) is the contents of
a[i]. I follow this perfectly, I think. The other definition that is
relevant, I thnk, is that the value of type array is the address of
element zero, so pa = a ( an array). All of this follows logically,
which is what I like about C.
So, now back to the original question.
All one is told is that pa is a pointer. From the first line in the
chapter, ( a pointer is a variable that contains the address of a
variable) I would be able to understand the logic that pa[i] would be
equivalent to (pa+i) ( the address of a[i]). I know a lot of poster
have said that this is not so, and I do not question it, I am just
trying to see where the logic of my comprehension is failing.
pa[i] is not equivalent to (pa+i). Instead it is equivalent to *(pa+i).

[] is inherently a dereferencing operator.

Just use the language. You'll get used to it.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Feb 12 '07 #17
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:
>>Of course lvalues are normally converted into the
value stored in the object denoted by the lvalue (as in the case of ai
in line 3) and this conversion does not happen when an lvalue is used
as an operand of certain operators, but I think is would be confusing
to call this conversion "deference".

In Algol 68, a[i] (an array element) and ai (a simple variable of
the same integer type) would have the same 'mode', both being
ref integer (if I recall correctly.) Algol then defines circumstances
under which a ref integer is automatically dereferenced .
Yes, Algol 68's value system includes references (values of mode ref
<mode>) and it simplifies the semantics of the language by making
variables expressions that yield values that are references. C does
not have reference values (or reference types) so I think that the
analogy with a language that has them just complicates the picture.

The analogy gets even messier since Algol 68's "ref"s behave somewhat
like pointers (they are, for example how you build linked lists and
trees). And it does not help that Algol 68 has *two* coercions from
ref modes -- weak and strong dereference.

By all means continue to consider that a[i] involves a dereference in
some places and not in others if that picture make things clear for
you. For beginners, I would reserve the term for the action of *
(turning a pointer into a lvalue -- the object to which it points)
and simply say (as the standard does) that lvalues are converted to
their contents in most situations.

--
Ben.
Feb 12 '07 #18
Christopher Layne <cl****@com.anodizedwrites:
[...]
I think the issue here is more so with lvalue vs rvalue and how
those play out rather than the [] operator itself. Ironically,
sizeof *p, in the example above, is not an lvalue nor is it actually
dereferencing the contents.
No, of course "sizeof *p" isn't an lvalue; the result of the sizeof
operator is never an lvalue. Its operand, *p, is an lvalue, but it's
not evaluated in this context.
Keith's point about the unary operator
is probably what's most important. Although does the language at
the end apply to sizeof?

If the operand has type "pointer to _type_", the result has type
"_type_". If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined.

int *p = (int *)rand(); sizeof *p;

Will the sizeof work on the deathstation 9k? It's got to, or
everyone doing p = malloc(sizeof *p); would be setting off nuclear
bombs.
The conversion itself may yield a trap representation; if so,
assigning it to p invokes undefined behavior. Assuming the result of
the conversion *isn't* a trap representation, the standard guarantees
that the operand of sizeof is not evaluated unless it's a VLA.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 12 '07 #19
Ben Bacarisse <be********@bsb.me.ukwrites:
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>>>If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .

OK, but I think it is confusing to talk about something being "used as
an lvalue". a[i] *is* an lvalue -- the wording about * says it is.
[...]

For "used as an lvalue", read "used in a context that requires an
lvalue".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 12 '07 #20
On Feb 12, 4:35 pm, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .
No it isn't
Suppose
a[i] = 5;
a[i] = 7;
a[i+1] = a[i] * 6;

Used on the left
hand side of an assignment, a[i] and *(a+i) can only be understood
in terms of denoting a -location- -- but the a[i] in the third
statement can only be understood in terms of delivering a -value-.
And yet the same operator is being used for the two.
This is a meaningless and confusing distinction. In
both cases, a[i] designates an object. It doesn't
matter whether you subsequently read or write the object.
The designation is applied before the object is read
or written, and in the same way in either case.
The code is entirely equivalent to:
ai = 5; ai = 7; aj = ai * 6;
except that different designators are used for the
memory locations.

Feb 12 '07 #21
Keith Thompson <ks***@mib.orgwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

If the [] operator *didn't* imply both the addition and the
dereference, then a[i] would be equivalent to (a+i). But it does, so
a[i] is equivalent to *(a+i).

It is arguable as to whether the [] operator implies a dereference
when it is used as an lvalue .

OK, but I think it is confusing to talk about something being "used as
an lvalue". a[i] *is* an lvalue -- the wording about * says it is.
[...]

For "used as an lvalue", read "used in a context that requires an
lvalue".
OK, that reading makes more sense but, for me, not quite enough.
There are two conversions at issue: (1) from a pointer to an object to
the lvalue of the object (the * in (a+i) and implicit in a[i]) and (2)
from an lvalue to the contents of the object. I prefer to use the
term dereference for (1) and I don't have a name for (2) -- it is just
part of expression evaluation¹ The standard does not use the word, so
this is just my preference from common usage and it looks to be the
meaning you use from the quote above.

If I understood him, Walter Robertson² was using dereference to refer
to this second, automatic, conversion from lvalue to contents. If so,
then it is not at all arguable -- section 6.3.2.1.2 lays out when it
happens and when it does not (left-hand side of assignment operators,
sizeof, & etc.) -- and it does not happen in those special "lvalue
requiring" contexts.

Calling * "dereference" is common-place and saying that [] might not
imply dereference muddies the already murky waters of the relationship
between variables, objects, pointers and lvalues.
¹ With all the exceptions such as when it is an operand of sizeof or
&, as listed in 6.3.2.1.2.

² I am not sure how to refer to authors of posts. Using a surname
seem too formal, and using a first name seem too informal (for someone
I don't know). Using both looks clumsy but I have to pick one.

--
Ben.
Feb 13 '07 #22
Harald van D?k wrote:
Christopher Layne wrote:
>int *p = (int *)rand(); sizeof *p;

Provided the conversion of rand's result does not result in a trap
representation, the sizeof also works. sizeof's argument is not
evaluated, and the behaviour is only undefined if the * operator is
evaluated. Otherwise, you couldn't even do

if (p != NULL)
*p = 5;
Right. I was really using it as an example to argue just the language of the
last part of:
>Keith Thompson wrote:
If the operand has type "pointer to _type_", the result has type
"_type_". If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined.
Feb 13 '07 #23

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

69
by: Ken | last post by:
Hi all. When referring to a null pointer constant in C++, is there any reason to prefer using 0 over a macro called NULL that is defined to be 0? Thanks! Ken
25
by: MC | last post by:
Hi I have the following piece of code. int *p; p = malloc(10); int *j; j = p; free(p); Is this legal ? will j still point to the same
44
by: Nicolas | last post by:
On most implementations of the standard C library, the functions that copy characters in a previously allocated buffer, like strcpy or strcat, are returning the pointer to that buffer. On my...
35
by: tuko | last post by:
Hello kind people. Can someone explain please the following code? /* Create Storage Space For The Texture */ AUX_RGBImageRec *TextureImage; /* Line 1*/ /* Set The Pointer To NULL...
204
by: Alexei A. Frounze | last post by:
Hi all, I have a question regarding the gcc behavior (gcc version 3.3.4). On the following test program it emits a warning: #include <stdio.h> int aInt2 = {0,1,2,4,9,16}; int aInt3 =...
9
by: Divick | last post by:
Hi all, I have a problem related to std::string class. Is it ok to assign a global string variable to a local string object as shown below? I am trying to print the address of local string...
51
by: Kuku | last post by:
What is the difference between a reference and a pointer?
8
by: Michael | last post by:
Hi all, why do I get a message: warning: passing arg 1 of `collectInput' from incompatible pointer type In 'main' have: char inputString; collectInput(&inputString);
83
by: deppy_3 | last post by:
Hi.I am started learning Programm language C before some time.I am trying to make a programm about a very simple "sell shop".This programm hasn't got any compile problem but when i run it i face...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.