Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Output of the printf(a,*a,**a) where a is of type int [][][]

Reply
Thread Tools

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

 
 
Richard
Guest
Posts: n/a
 
      02-05-2008
Keith Thompson <(E-Mail Removed)> writes:

> CBFalconer <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>> ... snip ...
>>>
>>> Yes, the program exhibits undefined behavior, and yes, that
>>> absolutely should be fixed, but that doesn't actually explain
>>> the behavior, and there is another explanation. There's
>>> nothing wrong with pointing out the undefined behavior *and
>>> then* answering the original question.

>>
>> Undefined behaviour can do _anything_.

>
> True.
>
>> No explanation is needed.

>
> 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.
 
Reply With Quote
 
 
 
 
Bartc
Guest
Posts: n/a
 
      02-05-2008

"Ravishankar S" <(E-Mail Removed)> wrote in message
news:fo8r2q$emr$(E-Mail Removed)...
> "Nikhil Bokare" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> #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.

--
Bart


 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      02-05-2008
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>CBFalconer <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>> ... snip ...
>>>
>>> Yes, the program exhibits undefined behavior, and yes, that
>>> absolutely should be fixed, but that doesn't actually explain
>>> the behavior, and there is another explanation. There's
>>> nothing wrong with pointing out the undefined behavior *and
>>> then* answering the original question.

>>
>> Undefined behaviour can do _anything_.

>
>True.
>
>> No explanation is needed.

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

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-05-2008
Bartc wrote:
> "Ravishankar S" <(E-Mail Removed)> wrote:
>

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      02-06-2008
CBFalconer wrote:

> Bartc wrote:
>> [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.)

--
Army1987 (Replace "NOSPAM" with "email")
 
Reply With Quote
 
Bartc
Guest
Posts: n/a
 
      02-06-2008
"CBFalconer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Bartc wrote:
>> "Ravishankar S" <(E-Mail Removed)> wrote:
>>

> ... 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);

}






 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-06-2008
"Bartc" <(E-Mail Removed)> writes:
> "CBFalconer" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Bartc wrote:
>>> "Ravishankar S" <(E-Mail Removed)> wrote:
>>>

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

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why is int a[0] not allowed, but int* a = new int[0] is? haijin.biz@gmail.com C++ 9 04-17-2007 09:01 AM
Difference between int i, j; and int i; int j; arun C Programming 8 07-31-2006 05:11 AM
int a[10]; int* p=(int*)((&a)+1); But why p isn't equal to ((&a)+1)? aling C++ 8 10-20-2005 02:42 PM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM
dirty stuff: f(int,int) cast to f(struct{int,int}) Schnoffos C Programming 2 06-27-2003 03:13 AM



Advertisments