469,632 Members | 1,681 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,632 developers. It's quick & easy.

question about pointer define

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.

Nov 15 '05 #1
28 2003
Wonder wrote on 08/09/05 :
// 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;


Not a C-code. C++ is next door.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."
Nov 15 '05 #2
i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.

Nov 15 '05 #3
"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.
No. p is an array of three pointers to int.
The star is just useless.
Definitely not. The parentheses are.
It can be showed by my program:

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

<snip>

This is by no means a C program. Either rewrite in C, or take this to
comp.lang.c++, please.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.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.
Nov 15 '05 #4
i don't think the elements in p are pointers, coz you even can't access
*p[i], i=0,1,2

if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.

BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?

Thanks.

Nov 15 '05 #5

Wonder wrote:
Hello,

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

It's the same as

int *p[3];

i.e., a 3-element array of pointers to int.
It seems if the parenthesis close p[3], it defines only 3 integers. The
star
is just useless.
The '*' indicates that p is an array of pointers to int, instead of
just an array of int.
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.

Right. What's happening is that the contents of p are uninitialized,
so p[0] through p[2] contain random bit strings, and these random bit
strings happened to be the same between the two runs. In the first
case, where p is declared as

int *(p[3]);

each element of p is of a *pointer* type, so the output is formatted to
reflect that (i.e., as hex values corresponding to a virtual memory
address). In the second case, where p is declared as

int (p[3]);

each element is of an *int* type, and the output is formatted to
reflect that.
The second line is comment-out, coz it'll be core dumped if you want to
get
the content of the pointer.

Right, because without proper initialization, p[0] through p[2] don't
point anywhere meaningful.
Could someone explain what's going on here? Thanks.


Basically, for any type T and declarator foo,

T *(foo);

is the same as

T *foo;

Nov 15 '05 #6
Wonder wrote:
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.
Wrong.
The star is just useless.
Wrong.
It can be showed by my program:
You program shows nothing. It is nothing but a bunch of syntax errors.
If you had posted it to <news:comp.lang.c++> instead, it would still be
garbage: no inclusion of needed the header file, no specification of the
needed namespace qualification.

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++
Which is not a C compiler, therefore not topical in <news:comp.lang.c>.
And it won't compile under g++ if you invoke g++ with appropriate
specification of diagnostics and of the standard used.

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


You're an idiot.
Nov 15 '05 #7
Wonder wrote:
i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.


Your code is not C. It is not loose C; it is not strict C; it is not
GNU C. It is in a different language.
Nov 15 '05 #8
Thanks a lot for your kind reply.

Now the problem goes to the difference between
int (*p)[3];
int *p[3];
int *(p[3]);

As you said, the second and the third are same. You are right, for
both, the *p[i] will give a core dump. However, the first one just give
the values of the elements, even though I didn't initialize anything.

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 output is:
440 -1869574000 -1869574000
0x6101cf3e 0x6101cf4a 0x6101cf56
0x6101cf3e 0x6101cf4a 0x6101cf56

Another strange thing is the second line and third line are same in
this case.

Nov 15 '05 #9
I didn't copy & paste the header coz I thought it had nothing to do
with the question itself, and I don't want to waste too many lines.

You just show the rudeness which should not represent the spirit of
comp.lang.c.

Nov 15 '05 #10

Wonder wrote:
i don't think the elements in p are pointers, coz you even can't access
*p[i], i=0,1,2

Because you haven't initialized them to point anywhere meaningful yet.
If you had done something like:

int x, y, z;
int *(p[3]) = {&x, &y, &z};

or
int *(p[3]);
p[0] = &x;
p[1] = &y;
p[2] = &z;

or even

p[0] = malloc(sizeof *p[0]);
p[1] = malloc(sizeof *p[1]);
p[2] = malloc(sizeof *p[2]);

*then* you could dereference each element.
if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.

No. Those two declarations do entirely different things:

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

In the case of

int *(p[3]);

or

int (*p[3]);

the parentheses are redundant and unnecessary; they do not add anything
to the declaration, and are the same as int *p[3]. So remember:

int p[3]; // p is a 3-element array of int;
int *p[3]; // p is a 3-element array of pointer to int,
int *(p)[3]; // same as above
int *(p[3]); // same as above
int (*p[3]); // same as above
int (*p)[3]; // p is a pointer to a 3-element array of int
BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?


Don't assume that everyone who knows C also knows C++ as well; it's
kind of like asking a question about Latin but using French to
illustrate the problem. C and C++ are just different enough that using
one to ask questions about the other could lead to misunderstandings
and mistakes.

Nov 15 '05 #11
"Wonder" <sa******@gmail.com> wrote:

[ about int *(p[3]); ]

Please preserve some context when you reply.
i don't think the elements in p are pointers,
They are. Just read the definition inside out, following the
precedence rules:

p p is ...
p[3] ... an array of three elements ...
(p[3]) ... (the ()s (are (just (noise)))) ...
*(p[3]) ... of pointers ...
int *(p[3]) ... to int. QED.
coz you even can't access
*p[i], i=0,1,2
But only because you didn't fill the array with sensible values.
if you make the parentheses close *p, or just erase parentheses, such
as
int (*p)[3] or int *p[3]

no problem, it's the definition of an array of three pointers to int.
Err, yes for the latter, no for the former:

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

It seems you're in dire need of a good C textbook.
BTW: is there a rule say that only C program can be written here, even
though the question is about C in nature?


Only C programs are of C in nature. ;-)

In other words: if you post code here, make sure it's C.
Additionally, you might want to follow the links in my signature
for an intersting reading.

Best regards
--
Irrwahn Grausewitz (ir*******@freenet.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.
Nov 15 '05 #12
> p p is ...
(*p) ... a pointer ...
(*p)[3] ... to an array of three ...
int (*p)[3] ... ints.
Thanks a lot! Your method is very useful.
In other words: if you post code here, make sure it's C.

I rewrite the program in pure C, here it is:

#include <stdio.h>
int main()
{
int (*p)[3];
/* printf("%x\t%x\t%x\n",*p[0],*p[1],*p[2]); */
printf("%x\t%x\t%x\n",p[0],p[1],p[2]);
printf("%x\t%x\t%x\n",&p[0],&p[1],&p[2]);
}

And I recompiled it by gcc under cygwin. The output is:
4 10 1c
4 10 1c

The first printf would cause core dump, but now I can understand it if
here p is a pointer to an int array which has 3 elements.
My question is why the second and third printf give the same result,
seems p[i] is same as &p[i] here.
Thanks.

Nov 15 '05 #13

Wonder wrote:
Thanks a lot for your kind reply.

Now the problem goes to the difference between
int (*p)[3];
int *p[3];
int *(p[3]);

As you said, the second and the third are same. You are right, for
both, the *p[i] will give a core dump. However, the first one just give
the values of the elements, even though I didn't initialize anything.

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 output is:
440 -1869574000 -1869574000
0x6101cf3e 0x6101cf4a 0x6101cf56
0x6101cf3e 0x6101cf4a 0x6101cf56

Another strange thing is the second line and third line are same in
this case.


IIRC, dereferencing an invalid or NULL pointer invokes undefined
behavior, meaning any output you get will be suspect.

As a matter of habit, I explicitly initialize pointers to NULL or a
valid memory location when I declare them, just to avoid these kinds of
problems.

Nov 15 '05 #14
"Wonder" <sa******@gmail.com> writes:
I didn't copy & paste the header coz I thought it had nothing to do
with the question itself, and I don't want to waste too many lines.


It's (almost) always best to post a small, complete, working,
self-contained program, something that the rest of us can
cut-and-paste and try for ourselves. If your program uses printf(),
add the required "#include <stdio.h>".

A missing include directive can cause unpredictable problems, problems
that your compiler won't necessarily diagnose. If you post what
appears to be an incomplete program, it's always possible that the
problem is in the part you didn't post. (If you knew enough to be
absolutely sure that that's not the case, you wouldn't be asking us
about it.)

Be sure to cut-and-paste the exact code that you compiled. If you
manually transcribe it, you're likely to introduce errors, and we'll
have no way of guessing where the real problem is if we can't see your
actual code.

And yes, posting C++ to comp.lang.c is in appropriate. Some of us
might happen to know what "cout << endl" means, but some of us may
not.

You're using groups.google.com, which unfortunately makes it far too
easy to post improperly. Don't assume that your readers can easily
see the article to which you're replying. Include enough quoted text
so someone can read each followup on its own, post your new text
*after* any quoted text, and provide proper attributions so we can
tell who said what. There is a way to do this (and this has been
posted here hundreds of times):

If you want to post a followup via groups.google.com, 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.

Finally, we get a lot of people coming here and making these same
mistakes. For each new poster, it's the first time; for us regulars,
it's the same thing over and over and over again. Sometimes the
frustration boils over a bit. The best solution is for new posters to
follow the newsgroup for a while, or browse the archives, to get an
idea of how things are done. Unfortunately, there doesn't seem to be
a good way to get the message out.

--
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.
Nov 15 '05 #15
"Wonder" <sa******@gmail.com> writes:
Irrwahn Grausewitz <ir*******@freenet.de> writes:

[attribution added]
p p is ...
(*p) ... a pointer ...
(*p)[3] ... to an array of three ...
int (*p)[3] ... ints.


Thanks a lot! Your method is very useful.
In other words: if you post code here, make sure it's C.

I rewrite the program in pure C, here it is:

#include <stdio.h>
int main()
{
int (*p)[3];
/* printf("%x\t%x\t%x\n",*p[0],*p[1],*p[2]); */
printf("%x\t%x\t%x\n",p[0],p[1],p[2]);
printf("%x\t%x\t%x\n",&p[0],&p[1],&p[2]);
}

And I recompiled it by gcc under cygwin. The output is:
4 10 1c
4 10 1c

The first printf would cause core dump, but now I can understand it if
here p is a pointer to an int array which has 3 elements.
My question is why the second and third printf give the same result,
seems p[i] is same as &p[i] here.


Let's try a modified version of your program.

#include <stdio.h>
#include <stdlib.h>
int main()
{
int (*p)[3];
p = malloc(sizeof *p);
if (p == NULL) {
exit(EXIT_FAILURE);
}
printf("p[0] = %p\n", (void*)p[0]);
printf("&p[0] = %p\n", (void*)&p[0]);
free(p);
return 0;
}

On one implementation, I get:

p[0] = 0x460210
&p[0] = 0x460210

As we've established, p is a pointer to an array of 3 ints.

You didn't initialize p, so its value is garbage. Any attempt to look
at whatever it points to invokes undefined behavior (I got a segmentation
fault). I've corrected this with the malloc() call.

The correct format for printing a pointer value is "%p", not "%x".
The "%p" format expects an argument of type void*; the casts are
necessary (even though you may be able to get away without them).

The prefix to an indexing operator [] is actually a pointer. If it's
the name of an array, as in
int arr[10];
arr[5];
the array name is implicitly converted to a pointer to its first
element. Since p is already a pointer, no such conversion is
necessary.

Remember that, by definition, x[y] is equivalent to *(x+y). In this
case, p[0] is equivalent to *(p+0), which is equivalent to *p. So the
expression p[0] gives you the thing that p points to, which happens to
be an array of 3 ints.

So p[0] is an array of 3 ints. In most contexts, an expression of
array type is implicitly converted to a pointer to its first element.
So in the printf() statement, p[0] is converted to a pointer-to-int,
and its value happens to be 0x460210. (Actually, it's pseudo-random
garbage, but we'll leave that aside for now.)

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

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.

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.

--
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.
Nov 15 '05 #16
Wonder wrote:
You just show the rudeness
which should not represent the spirit of comp.lang.c.


It doesn't.
You have just met some of our indigenous trolls.
They pounce on every new subscriber.
You must learn to recognize them and ignore them.
Nov 15 '05 #17
On 8 Sep 2005 11:26:40 -0700, "Wonder" <sa******@gmail.com> wrote in
comp.lang.c:
i'm just using cout to output. It has nothing to do with the nature of
the question here.
I'm new here, don't know we have to write strict C code.


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.

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.

Whether the meaning of the declaration in C++ is the same as it is in
C is a matter for comp.lang.c++, since C does not define any
compatibility with C++. It is C++, rather, that defines backwards
compatibility with C. The C++ language standard incorporates parts of
an older, out-of-date version of the C standard, not vice-versa.

So while posters in this group could explain what the declaration
means in C, that is not necessarily what it means in your C++ (or Java
or C# of FORTRAN or ADA) program.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 15 '05 #18

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

Nov 15 '05 #19
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Wonder wrote:
You just show the rudeness
which should not represent the spirit of comp.lang.c.


It doesn't.
You have just met some of our indigenous trolls.
They pounce on every new subscriber.
You must learn to recognize them and ignore them.


ERT himself is our most persistent indigenous troll. He has a long
history of posting misinformation.

--
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.
Nov 15 '05 #20

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_FAILURE);
}
*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!

Nov 15 '05 #21

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.

Nov 15 '05 #22
"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_FAILURE);
}
*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*******@freenet.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.
Nov 15 '05 #23
"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_FAILURE);
}
*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_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.
Nov 15 '05 #24
Keith Thompson <ks***@mib.org> 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*******@freenet.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.
Nov 15 '05 #25
Irrwahn Grausewitz <ir*******@freenet.de> writes:
Keith Thompson <ks***@mib.org> 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_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.
Nov 15 '05 #26
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



Nov 15 '05 #27
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 ---
Nov 15 '05 #28
"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.com. It makes it
gratuitiously difficult, but not impossible, to post properly.

If you want to post a followup via groups.google.com, 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_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.
Nov 15 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Dmitry D | last post: by
33 posts views Thread by Mohanasundaram | last post: by
3 posts views Thread by Bryan Parkoff | last post: by
36 posts views Thread by Bhalchandra Thatte | last post: by
9 posts views Thread by Arun Prasath | last post: by
24 posts views Thread by ark | last post: by
10 posts views Thread by Kieran Simkin | last post: by
10 posts views Thread by masood.iqbal | last post: by
18 posts views Thread by steve | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.