question about pointer define

[Wonder]

Hello,

I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless. It can be showed by my program:

int main()
{
int *(p[3]);
// cout << *p[0] << "\t" << *p[1] << "\t" << *p[2] << endl;
cout << &p[0] << "\t" << &p[1] << "\t" << &p[2] << endl;
cout << p[0] << "\t" << p[1] << "\t" << p[2] << endl;
}

The program can be compiled on cygwin linux by g++ and run, the output
is:

0x22efb0 0x22efb4 0x22efb8
0x76c 0xffffffff 0x22efc8

If you delete the * in the definition, define int (p[3]); the second
line
will be:

1900 -1 2289608

Which is exactly the decimal numbers of the the previous program.

The second line is comment-out, coz it'll be core dumped if you want to
get
the content of the pointer.

Could someone explain what's going on here? Thanks.

[Wonder]

Keith Thompson wrote:

Note that we considered this conversion rule in two different
contexts. For p, the prefix to the indexing operator, the rule
doesn't apply, because p is already a pointer (to an array of 3 ints).
For p[0], an array of 3 ints, the rule does apply, and it's converted
to a pointer-to-int.

In fact, after reading your program and explain, I doubt the compiler
just output the address of a pointer points to, no matter you are using
p or &p. The following program can prove it:

#include <stdio.h>
#include <stdlib.h>

int main()
{
int *p = NULL;
p = malloc(sizeof *p);
if (p == NULL)
{
exit(EXIT_FAILU RE);
}
*p = 10;
printf("p=%p\n" , (void*)p);
printf("&p=%p\n ", (void*)p);
printf("*p=%d\n ", *p);
free(p);
return 0;
}

It can be compiled by gcc on Linux, and the output is:

p=0x8049678
&p=0x8049678
*p=10

In the second printf, we apply the "&" (address-of) operator to p[0].
This is one of the contexts in which the conversion to pointer
*doesn't* take place. (Another is the operand of the sizeof
operator.) So &p[0] is the address of an array-of-3-ints. p[0] and
&p[0] have different types, but they yield the same raw pointer value
when converted to void* and printed with "%p".

Could you explain in which contexts such conversion doesn't take place?
And in your original program, p[1] actually refers to *another* array
of 3 ints, the second element of the array of arrays-of-3-ints to
which p points. In my version of your program, I only allocated
enough memory for a single array-of-3-ints; if I wanted to play with
p[1], I'd have to allocate more memory.

So, does that mean we have 3 pointers p[0], p[1], p[2], and each one
points
to an array of 3 integers? But we are not defining an array of
pointers, right?
This all seems confusing because, frankly, it is. I went down a
couple of blind alleys while writing this, and I'm not at all certain
that there are no errors in what I've written.

There really aren't many cases where it makes sense to have a pointer
to an array of 3 ints. Usually it makes much more sense to have a
pointer to int, which can be used to access an array of ints. If you
really need an array of items, where each item contains 3 ints, you
might be better off wrapping the array-of-3-ints in a struct and
declaring a pointer to the struct type. Even if you can keep the
complications of a pointer-to-fixed-size-array-of-whatever straight in
your head, the next person to read your code may not be able to.

For a better general understanding of the relationship between arrays
and pointers, read section 6 of the C FAQ,
<http://www.eskimo.com/~scs/C-faq/faq.html>. (In fact, read the whole
thing if you haven't already.)

And before assuming that everything I've written here is correct, wait
a while until the other regulars have had a chance to pick it apart.

You are absolutely right. I never use pointers to an array. Here I just
want to make the concept clear.
Thanks a lot. You are so nice!

[Wonder]

Jack Klein wrote:

Please provide context when you follow-up or reply to a post. There
have been any number of posts around here explaining how to do this
properly using the broken Google groups, or get yourself a real
newsreader.

Sorry about that. Actually, I'm using Outlook Express 6 to read, but
the free NNTP server news://freenews.netfront.net doesn't allow me to
post. That's why I have to use Google groups to post. Do you know any
free news server allows post? Thanks.
The issue about C++ code is this: your sample program is written in
C++, not in C. Your original question was about the meaning of the
declaration 'int *(p[3]);'. We cannot answer that question here in
the context of C++, only in the context of C, which does not apply to
your sample program.

I understand what you said. I'll stick to pure C in this group in the
future. Thanks.

[Irrwahn Grausewitz]

"Wonder" <sa******@gmail .com> wrote:

Keith Thompson wrote:

Note that we considered this conversion rule in two different
contexts. For p, the prefix to the indexing operator, the rule
doesn't apply, because p is already a pointer (to an array of 3 ints).
For p[0], an array of 3 ints, the rule does apply, and it's converted
to a pointer-to-int.
In fact, after reading your program and explain, I doubt the compiler
just output the address of a pointer points to, no matter you are using
p or &p. The following program can prove it:

#include <stdio.h>
#include <stdlib.h>

int main()
{
int *p = NULL;
p = malloc(sizeof *p);
if (p == NULL)
{
exit(EXIT_FAILU RE);
}
*p = 10;
printf("p=%p\n" , (void*)p);
printf("&p=%p\n ", (void*)p);

ITYM:
printf("&p=%p\n ", (void*)&p);
printf("*p=%d\n ", *p);
free(p);
return 0;
}

It can be compiled by gcc on Linux, and the output is:

p=0x8049678
&p=0x8049678
Which will be different with the code correction above applied.
*p=10

In the second printf, we apply the "&" (address-of) operator to p[0].
This is one of the contexts in which the conversion to pointer
*doesn't* take place. (Another is the operand of the sizeof
operator.) So &p[0] is the address of an array-of-3-ints. p[0] and
&p[0] have different types, but they yield the same raw pointer value
when converted to void* and printed with "%p".
Could you explain in which contexts such conversion doesn't take place?

An array "decays" into a pointer, except when it is the operand of the
address operator & or the sizeof operator. (Another exception are
string literals used to initialize arrays.) Consider:

int arr[42];

arr /* arr is converted to a pointer to its first element, the
type of the expression is pointer-to-int. */

arr[1] /* arr is again converted, the value of the expression is
*(arr+1), its type is int. */

&arr /* No conversion of arr, value of the expression is the same
as above (the address of the array equals the address of
its first element). The type however is pointer-to-array.
*/

sizeof arr /* No conversion, value is the size of the array. */
Now back to our original example:

int (*p)[3] /* p is a pointer-to-array-of-three-ints */

p[0] /* Per definition, this is equivalent to: *(p + 0),
which yields an array, which in turn decays into a
pointer to it's first element, a pointer-to-int. */

&p[0] /* Per definition, this is equivalent to (p + 0), a
pointer-to-array-of-three-ints. */

Note that the two latter expressions yield the same value (memory
address), but are of different type!

And in your original program, p[1] actually refers to *another* array
of 3 ints, the second element of the array of arrays-of-3-ints to
which p points. In my version of your program, I only allocated
enough memory for a single array-of-3-ints; if I wanted to play with
p[1], I'd have to allocate more memory.

So, does that mean we have 3 pointers p[0], p[1], p[2], and each one
points
to an array of 3 integers? But we are not defining an array of
pointers, right?

Right, but remember that the array subscription operator [] is nothing
but syntactic sugar for *(p + index). Thus we can use array
subscription on any old object pointer if we like. However, in the
mentioned case, we indeed refer to memory we don't own.
[...] I never use pointers to an array. [...]

A wise decision, since they are hardly useful anyway. ;-)

Best regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Keith Thompson]

"Wonder" <sa******@gmail .com> writes:

Keith Thompson wrote:

Note that we considered this conversion rule in two different
contexts. For p, the prefix to the indexing operator, the rule
doesn't apply, because p is already a pointer (to an array of 3 ints).
For p[0], an array of 3 ints, the rule does apply, and it's converted
to a pointer-to-int.

In fact, after reading your program and explain, I doubt the compiler
just output the address of a pointer points to, no matter you are using
p or &p. The following program can prove it:

#include <stdio.h>
#include <stdlib.h>

int main()
{
int *p = NULL;
p = malloc(sizeof *p);
if (p == NULL)
{
exit(EXIT_FAILU RE);
}
*p = 10;
printf("p=%p\n" , (void*)p);
printf("&p=%p\n ", (void*)p);
printf("*p=%d\n ", *p);
free(p);
return 0;
}

It can be compiled by gcc on Linux, and the output is:

p=0x8049678
&p=0x8049678
*p=10

You have a typo; your first and second printf() calls both print the
same value. After changing the second printf() to
printf("&p=%p\n ", (void*)p);
I get:

p=0x460210
&p=0x22ef14
*p=10

In the second printf, we apply the "&" (address-of) operator to p[0].
This is one of the contexts in which the conversion to pointer
*doesn't* take place. (Another is the operand of the sizeof
operator.) So &p[0] is the address of an array-of-3-ints. p[0] and
&p[0] have different types, but they yield the same raw pointer value
when converted to void* and printed with "%p".

Could you explain in which contexts such conversion doesn't take place?

Quoting the standard (C99 6.3.2.1p3):

Except when it is the operand of the sizeof operator or the unary
& operator, or is a string literal used to initialize an array, an
expression that has type "array of type" is converted to an
expression with type "pointer to type" that points to the initial
element of the array object and is not an lvalue. If the array
object has register storage class, the behavior is undefined.

And in your original program, p[1] actually refers to *another* array
of 3 ints, the second element of the array of arrays-of-3-ints to
which p points. In my version of your program, I only allocated
enough memory for a single array-of-3-ints; if I wanted to play with
p[1], I'd have to allocate more memory.

So, does that mean we have 3 pointers p[0], p[1], p[2], and each one
points to an array of 3 integers? But we are not defining an array
of pointers, right?

Yes and no. It depends on what you mean by "pointer". The term
usually refers to a pointer *object*, but it can also refer to a
pointer *value* (also known as an address) -- yet another source of
confusion.

Recall that p is a pointer to array-of-3-ints. So let's say we
allocate enough memory for 3 such arrays:

p = malloc(9 * sizeof int);

Then each of p[0], p[1], and p[2] is an array of 3 ints. p itself is
the only pointer object in sight, but you can construct a pointer to
(the address of) any object. It happens that the expression p[1]
evaluates to a pointer value (because of the implicit array-to-pointer
conversion), but p[1] itself is an array object.

--
Keith Thompson (The_Other_Keit h) 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.

[Irrwahn Grausewitz]

Keith Thompson <ks***@mib.or g> wrote:

"Wonder" <sa******@gmail .com> writes: <snip>

printf("p=%p\n" , (void*)p);
printf("&p=%p\n ", (void*)p);

<snip>You have a typo; your first and second printf() calls both print the
same value. After changing the second printf() to
printf("&p=%p\n ", (void*)p);

<snip>

Cough. Change? Which change? ;^)

Best regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc frequent answers: http://benpfaff.org/writings/clc.

[Keith Thompson]

Irrwahn Grausewitz <ir*******@free net.de> writes:

Keith Thompson <ks***@mib.or g> wrote:

"Wonder" <sa******@gmail .com> writes:

<snip>

printf("p=%p\n" , (void*)p);
printf("&p=%p\n ", (void*)p);

<snip>

You have a typo; your first and second printf() calls both print the
same value. After changing the second printf() to
printf("&p=%p\n ", (void*)p);

<snip>

Cough. Change? Which change? ;^)

D'oh!

--
Keith Thompson (The_Other_Keit h) 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.

[Lawrence Kirby]

On Thu, 08 Sep 2005 22:38:43 +0000, Malcolm wrote:

"Wonder" <sa******@gmail .com> wrote

I'm confused by the pointer definition such as int *(p[3]);

It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless. It can be showed by my program:
Everyone else is also confused, except maybe a few C rules lawyers.

The problem is that C allows you to define pointers to complex compound
types, such as arrays of arbitrary dimensions. The syntax very rapidly
becomes non-human understandable.

Here we have a pointer to an array of three integers.

int *(p[3]) declares p as an array of 3 pointers to int, it is not a
pointer to an array. Since [] naturally binds more tightly than * the
parentheses here are redundant, and it is equivalent to int *p[3]. A
pointer to an array of 3 ints would be written as int (*p)[3].
The declaration int
*p[3] would be an array of three pointers to an integer.
However under the bonnet a pointer to an array of three integers and a
pointer to an integer (which may have other integers follwing it
contiguously in memory) is the same. To avoid the confusion that results, a
wise C programmer will always use a plain int *, and specify in the comment
above the function if necessary that the pointer must point to exactly three
integers, or to a list of triplets if that is the intention.

The 3 types int *, int *[3] and int (*)[3] have different properties, you
cannot simply substitute one for another. int * will NOT do when you want
int *[3]. As for int (*)[3] it is used for arrays of arrays e.g.

int a[4][3];
int (*p)[3] = a;
int (*q)[3] = malloc(4 * sizeof *q);

if (q == NULL) { /* Deal with error */ };

Now p[2][1] will access element a[2][1], q[2][1] will do the same thing
for a dynamically allocated array of arrays. Making p or q int * will not
work here.

Lawrence

[Joe Wright]

Wonder wrote:

Jack Klein wrote:

Please provide context when you follow-up or reply to a post. There
have been any number of posts around here explaining how to do this
properly using the broken Google groups, or get yourself a real
newsreader.

Sorry about that. Actually, I'm using Outlook Express 6 to read, but
the free NNTP server news://freenews.netfront.net doesn't allow me to
post. That's why I have to use Google groups to post. Do you know any
free news server allows post? Thanks.

I would use Google and search 'free news server' or something like that.
Do you use an ISP that doesn't supply news? Do you get mail?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

"Wonder" <sa******@gmail .com> writes:

Jack Klein wrote:

Please provide context when you follow-up or reply to a post. There
have been any number of posts around here explaining how to do this
properly using the broken Google groups, or get yourself a real
newsreader.

Sorry about that. Actually, I'm using Outlook Express 6 to read, but
the free NNTP server news://freenews.netfront.net doesn't allow me to
post. That's why I have to use Google groups to post. Do you know any
free news server allows post? Thanks.

No, I don't. (I think news.individual .net recently stopped offering
free accounts.)

Most ISPs offer Usenet access; does yours?

If not, you can still use groups.google.c om. It makes it
gratuitiously difficult, but not impossible, to post properly.

If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

--
Keith Thompson (The_Other_Keit h) 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.