Output of the printf(a,*a,**a) where a is of type int [][][]

[Richard]

Nonsense. It was obvious from the beginning that the OP was
attempting to print the values of a, *a, **a, and &a, and wanted to
know why they all appeared to have the same value. He clearly did
require an explanation (i.e., he came to us for help), and digging
through the undefined behavior to get to what he was actually asking
about was easy enough that several of us managed to do it.

A C program can behave in arbitrarily obnoxious ways in the presence
of undefined behavior. We don't have to do likewise.

Mr CBFalconer does not seem happy unless he is being curt and rude to a
new poster. I sometimes wonder why you can other more useful people even
bother replying to his obnoxious nonsense.

 

[Bartc]

#include<stdio.h>

int main()
{
int a[3][3][3];
printf("%d %d %d %d",a,*a,**a,&a);
}

I tried the above code and got the same value for a, *a , **a and &a.
Can anyone please tell me the reason behind such a behavior?

http://web.torek.net/torek/c/pa.html

That's a pretty good link, especially
http://web.torek.net/torek/c/expr.html#therule a bit further on.

Text that tells you /about/ the language rather than try and teach you
programming.

[The 'rule'] "It falls out from a key fact: C does not have array values"

Finally someone has pointed out the elephant in the drawing room, or
whatever the saying is.

 

[Kenny McCormack]

Nonsense. It was obvious from the beginning that the OP was
attempting to print the values of a, *a, **a, and &a, and wanted to
know why they all appeared to have the same value. He clearly did
require an explanation (i.e., he came to us for help), and digging
through the undefined behavior to get to what he was actually asking
about was easy enough that several of us managed to do it.

A C program can behave in arbitrarily obnoxious ways in the presence
of undefined behavior. We don't have to do likewise.

Oh. The. Irony...

 

[CBFalconer]

.... snip ...

http://web.torek.net/torek/c/pa.html

That's a pretty good link, especially
http://web.torek.net/torek/c/expr.html#therule a bit further on.

Text that tells you /about/ the language rather than try and
teach you programming.

[The 'rule'] "It falls out from a key fact: C does not have array
values"

Except that is wrong. However, C doesn't pass array values.

 

[Army1987]

[The 'rule'] "It falls out from a key fact: C does not have array
values"

Except that is wrong. However, C doesn't pass array values.

6.3.2.1
Except when it is the operand of the sizeof operator, the unary & operator, the ++
operator, the -- operator, or the left operand of the . operator or an assignment operator,
an lvalue that does not have array type is converted to the value stored in the designated
object (and is no longer an lvalue).

This cannot happen with arrays. (Well, here "value" is what some people
call a rvalue, but the standard does also define what the "value of a
string" is.)

 

[Bartc]

... snip ...

http://web.torek.net/torek/c/pa.html

That's a pretty good link, especially
http://web.torek.net/torek/c/expr.html#therule a bit further on.

Text that tells you /about/ the language rather than try and
teach you programming.

[The 'rule'] "It falls out from a key fact: C does not have array
values"

Except that is wrong. However, C doesn't pass array values.

See the code below. When you use 'a' in an expression, you don't get the
'value' of that term as you would with pretty much any other type. You get,
well I don't know what, some sort of pointer, which was my gripe elsewhere.

The two lines printing **p and **a, show the absurdity of the consequences:
p is clearly a pointer to a pointer, and merits the 2 stars. But a is an
array, with no pointer in sight, yet is still dereferenced 2 times. (Unless
C arrays are implemented using pointers? But I don't believe that.)

Contrast with another language which does have array values:

a:=((10,20,30),(40,50,60),(70,80,90))
println a

Output:
(( 10, 20, 30),( 40, 50, 60),( 70, 80, 90))

Bart

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

int main(void)
{int a[3][3] = {{10,20,30},{40,50,60},{70,80,90}};

int x=123;
int *q=&x;
int **p=&q;

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

printf("**a = %d\n",(int)**a);

}

 

[Keith Thompson]

... snip ...

http://web.torek.net/torek/c/pa.html

That's a pretty good link, especially
http://web.torek.net/torek/c/expr.html#therule a bit further on.

Text that tells you /about/ the language rather than try and
teach you programming.

[The 'rule'] "It falls out from a key fact: C does not have array
values"

Except that is wrong. However, C doesn't pass array values.

Agreed. However, let me point out once again that the implicit
conversion of an array to a pointer to the array's first element has
nothing to do with function argument passing. That's just one
instance in which it happens, among many others -- in fact, the
conversion happens in *all* contexts *except* when the array is the
operarand of a unary "sizeof" or "&" operator, or when it's a string
literal used to initialize an array. Argument passing is perhaps the
most common and visible example, but the emphasis on argument passing
tends to obscure the fact that the conversion happens in many other
contexts. (There's also the fact that what looks like an array
parameter declaration is really a pointer parameter declaration, but
that's a separate issue; the two rules are related, but neither
actually depends on the other.)

See the code below. When you use 'a' in an expression, you don't get the
'value' of that term as you would with pretty much any other type. You get,
well I don't know what, some sort of pointer, which was my gripe elsewhere.

You get a pointer to the first element of the array (or, equivalently,
the address of the first element of the array).

The two lines printing **p and **a, show the absurdity of the consequences:
p is clearly a pointer to a pointer, and merits the 2 stars. But a is an
array, with no pointer in sight, yet is still dereferenced 2 times. (Unless
C arrays are implemented using pointers? But I don't believe that.)

No C arrays are not (necessarily) implemented using pointers. More
precisely, a declaration such as
int a[3][3];
does not create any implicit pointer *object*. But as with any object
declaration, there are objects whose address can be taken, yielding
pointer *values*. The rules for array expressions result in such
pointer values being created implicitly in many contexts.

C's treatment of arrays and pointers is unusual compared to some other
languages, but once you understand a few basic rules, it all really
does make sense. The problem is that C's syntax almost seems designed
to make you *think* that arrays and pointers are equivalent in some
way. If you approach the problem without an understanding of the
underlying rules, it's easy to draw incorrect conclusions or just to
become hopelessly confused.

The best cure I know for the confusion is to read and understand
section 6 of the comp.lang.c FAQ, <http://www.c-faq.com>.

[snip]