473,387 Members | 1,575 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,387 software developers and data experts.

printf("%d",*(&ptr2 + 2))

Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
Jun 27 '08 #1
27 2059
sophia wrote:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
Where do people find these contrived examples?

The answer is luck. I just happens that's the way the variables are
laid out in memory.

Try building 64 bit and see what you get then.

--
Ian Collins.
Jun 27 '08 #2
On Apr 25, 12:56*pm, Ian Collins <ian-n...@hotmail.comwrote:
sophia wrote:
Dear all,
why in the following program
*#include<stdio.h>
*#include<stdlib.h>
*int main(void)
*{
* *int x[] = {99,2,3,4,5};
* *int *ptr,**ptr2;
* *ptr *= x;
* *ptr2 = &ptr;
* *printf("%d",*(&ptr2 + 2));
* *return EXIT_SUCCESS;
*}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

Where do people find these contrived examples?

The answer is luck. *I just happens that's the way the variables are laid out in memory.
There is something more than luck, that is my conclusion.

I tried changing the value of x[0] to different values but still
it will print the o/p correctly.

Has it any thing to do with the compiler ?

I checked this program on lcc-win32 compiler
Try building 64 bit and see what you get then.
I don't have a 64 bit compiler
Jun 27 '08 #3
sophia wrote:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
What it prints is purely by chance.
Did your compiler not produce a warning?
What is the type of &ptr2? It's int ***. What is the type of (&ptr2 +
2). Again the same. Then what's the type of *(&ptr2 + 2)? It's int **.
What type does %d expect. It expects an int.

What you want is:

printf("%d\n", **ptr2);

Jun 27 '08 #4
sophia wrote:
On Apr 25, 12:56*pm, Ian Collins <ian-n...@hotmail.comwrote:
>sophia wrote:
Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr *= x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the
array x ? can anybody explain ?

Where do people find these contrived examples?

The answer is luck. *I just happens that's the way the variables are
laid out in memory.

There is something more than luck, that is my conclusion.
Your conclusion is wrong. What it prints is purely by chance, since
there is a type discrepancy between what printf expects and what it
gets.
I tried changing the value of x[0] to different values but still
it will print the o/p correctly.
That's irrelevant.
Has it any thing to do with the compiler ?
Certainly your output, because your program invokes undefined behaviour,
is likely to be specific to your implementation or even specific to
each run of the program.
I checked this program on lcc-win32 compiler
>Try building 64 bit and see what you get then.
I don't have a 64 bit compiler
Jun 27 '08 #5
sophia wrote:
On Apr 25, 12:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
>sophia wrote:
>>Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr = x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
Where do people find these contrived examples?

The answer is luck. I just happens that's the way the variables are laid out in memory.

There is something more than luck, that is my conclusion.

I tried changing the value of x[0] to different values but still
it will print the o/p correctly.
The luck is in the memory layout, not the values. The address of &ptr2
+ 2 just happens to be the address of x[0].
Has it any thing to do with the compiler ?
Everything, memory layout is compiler and platform specific, although
most 32 bit compilers on x86 probably use the same layout.
I don't have a 64 bit compiler
Every home should have one :)

--
Ian Collins.
Jun 27 '08 #6
sophia said:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
The program is broken. In any case, it's overly complex for its job.

First, decide what you want to print. Then try to think of the simplest
reasonable way to print it. If you get stuck with that, let us know.

For example, it would appear from the above that you wish to print the
number 3. The simplest way to do this is as follows:

#include <stdio.h>

int main(void)
{
puts("3");
return 0;
}

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #7
On Apr 25, 2:31*pm, Richard Heathfield <r...@see.sig.invalidwrote:
sophia said:


Dear all,
why in the following program
*#include<stdio.h>
*#include<stdlib.h>
*int main(void)
*{
* *int x[] = {99,2,3,4,5};
* *int *ptr,**ptr2;
* *ptr *= x;
* *ptr2 = &ptr;
* *printf("%d",*(&ptr2 + 2));
* *return EXIT_SUCCESS;
*}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

The program is broken. In any case, it's overly complex for its job.

First, decide what you want to print. Then try to think of the simplest
reasonable way to print it. If you get stuck with that, let us know.

For example, it would appear from the above that you wish to print the
number 3. The simplest way to do this is as follows:

#include <stdio.h>

int main(void)
{
* puts("3");
* return 0;

}
you see, i am not playing games by printing numbers. this is a
question which was asked in an interview
Jun 27 '08 #8
sophia wrote:
<snip>
) * *int x[] = {99,2,3,4,5};
) * *int *ptr,**ptr2;
)>
) * *ptr *= x;
) * *ptr2 = &ptr;
)>
) * *printf("%d",*(&ptr2 + 2));
<snip>
)>
) printf("%d",*(&ptr2 + 2)); is printing the first element of the array
) x ? can anybody explain ?
<snip>
)
) you see, i am not playing games by printing numbers. this is a
) question which was asked in an interview

Then it's not a very good interview, unless they're looking for very
specific in-depth knowledge on how a specific compiler works.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Jun 27 '08 #9
sophia said:
On Apr 25, 2:31 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>sophia said:


Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr = x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

The program is broken. In any case, it's overly complex for its job.
<snip>
you see, i am not playing games by printing numbers. this is a
question which was asked in an interview
Fine, then the answer is easy. "The program is broken, because the
expression (&ptr2 + 2) forms an illegal pointer value." That will get you
full marks, provided that the interviewer knows C. If the interviewer only
/thinks/ he knows C, either become a mind-reader very quickly or look
elsewhere for a job.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #10
sophia wrote:
On Apr 25, 2:31*pm, Richard Heathfield <r...@see.sig.invalidwrote:
>sophia said:


Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr *= x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the
array x ? can anybody explain ?

The program is broken. In any case, it's overly complex for its job.

First, decide what you want to print. Then try to think of the
simplest reasonable way to print it. If you get stuck with that, let
us know.

For example, it would appear from the above that you wish to print
the number 3. The simplest way to do this is as follows:

#include <stdio.h>

int main(void)
{
puts("3");
return 0;

}

you see, i am not playing games by printing numbers. this is a
question which was asked in an interview
Unless the interviewer provided specific additional details regarding
the memory layout of the implementation, the question is broken and the
program is undefined according to the language standard. You might try
seeking a job elsewhere. Even if it were to be assumed that the
array 'x' starts 2 * sizeof &ptr2 bytes after &ptr2, the program is
still broken because the printf call is incorrect.

Jun 27 '08 #11
Richard Heathfield wrote:
sophia said:
>Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

The program is broken. In any case, it's overly complex for its job.

First, decide what you want to print. Then try to think of the
simplest reasonable way to print it. If you get stuck with that, let
us know.

For example, it would appear from the above that you wish to print the
number 3. The simplest way to do this is as follows:

#include <stdio.h>

int main(void)
{
puts("3");
return 0;
}
Even simpler and correct would be:

/* begin code */
#include <stdio.h>

int main(void)
{
putc('3', whatever_stream);
return 0;
}
/* end code */

:-)

Jun 27 '08 #12
In article <sl********************@snail.stack.nl>,
Willem <wi****@stack.nlwrote:
>) you see, i am not playing games by printing numbers. this is a
) question which was asked in an interview
>Then it's not a very good interview, unless they're looking for very
specific in-depth knowledge on how a specific compiler works.
Or they're looking for someone who knows that it depends on the
compiler, and who is able to explain why it's quite likely to produce
a certain result on typical implementations.

-- Richard
--
:wq
Jun 27 '08 #13
On Fri, 25 Apr 2008 00:51:33 -0700 (PDT), sophia
<so**********@gmail.comwrote:
>Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
As it stands, your code invokes undefined behavior because the second
argument is not the int that the %d promises printf it would be.

If you change the & to an *, I think it will do what you want.
Remove del for email
Jun 27 '08 #14
On Apr 25, 1:38*am, sophia <sophia.ag...@gmail.comwrote:
On Apr 25, 2:31*pm, Richard Heathfield <r...@see.sig.invalidwrote:


sophia said:
Dear all,
why in the following program
*#include<stdio.h>
*#include<stdlib.h>
*int main(void)
*{
* *int x[] = {99,2,3,4,5};
* *int *ptr,**ptr2;
* *ptr *= x;
* *ptr2 = &ptr;
* *printf("%d",*(&ptr2 + 2));
* *return EXIT_SUCCESS;
*}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
The program is broken. In any case, it's overly complex for its job.
First, decide what you want to print. Then try to think of the simplest
reasonable way to print it. If you get stuck with that, let us know.
For example, it would appear from the above that you wish to print the
number 3. The simplest way to do this is as follows:
#include <stdio.h>
int main(void)
{
* puts("3");
* return 0;
}

you see, i am not playing games by printing numbers. this is a
question which was asked in an interview- Hide quoted text -

- Show quoted text -
What do you think would happen if you changed
int *ptr, **ptr2;
to
int **ptr2, *ptr;
?
Try answering it before you program it.
Do you know *why* that is the result?
--
Fred Kleinschmidt
Jun 27 '08 #15
On Apr 25, 1:07 pm, santosh <santosh....@gmail.comwrote:
sophia wrote:
Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr = x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

What it prints is purely by chance.
Did your compiler not produce a warning?
What is the type of &ptr2? It's int ***. What is the type of (&ptr2 +
2). Again the same. Then what's the type of *(&ptr2 + 2)? It's int **.
What type does %d expect. It expects an int.
I have a doubt over here(doubt, not question, because I doubt what I
think is true). I think your reasoning is wrong here. &ptr2 is value
of address type. &ptr + 2 is also an address location. *(address
location) gives the value stored at that location which is being
interpreted as int because of the %d. It is a different matter that
the memory layout had the array preceded by the pointer declarations
but apart from that, the print statement is valid. Please correct me
if I am wrong.
What you want is:

printf("%d\n", **ptr2);
What part of Sophia's code led you to believe that was what she wanted?
Jun 27 '08 #16
On Apr 25, 12:51 pm, sophia <sophia.ag...@gmail.comwrote:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
while others have already talked about the code being broken and
all... and assuming the code works, I think the interviewer assumed
for granted that the stack grows from higher address to low. Now since
both a pointer to an int and a pointer to pointer will have same size
(regulars please correct me if I am wrong on this), (&ptr2 + 2) would
point to the memory location after the space for the two pointers.
This happens to be the start of the array in this particular case.
Because the format specified is %d, the compiler considers the integer
value of whatever is present at that location. (I might be very wrong
in this answer, please correct me).

Harsha
Jun 27 '08 #17
Sri Harsha Dandibhotla wrote:
On Apr 25, 1:07 pm, santosh <santosh....@gmail.comwrote:
>sophia wrote:
Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr = x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the
array x ? can anybody explain ?

What it prints is purely by chance.
Did your compiler not produce a warning?
What is the type of &ptr2? It's int ***. What is the type of (&ptr2 +
2). Again the same. Then what's the type of *(&ptr2 + 2)? It's int
**. What type does %d expect. It expects an int.

I have a doubt over here(doubt, not question, because I doubt what I
think is true). I think your reasoning is wrong here. &ptr2 is value
of address type.
It's a value of type int ***.
&ptr + 2 is also an address location.
I think you meant &ptr2 + 2. This also yields a value of type int ***,
but it needn't be an address that can legally be addressed. ptr2 points
(in the code given) to a single int * (i.e., ptr). Hence *ptr2 is okay,
**ptr2 is okay (since ptr has been initialised to point to an int[5]
object), but constructs like *(ptr2+1) or **(ptr2+1) might deference
invalid locations. So will *(&ptr2 + 2). What happens in practise
depends on the relative memory layouts of ptr, ptr2 and the array x,
something that will very likely vary from compiler to compiler or from
compilation to compilation, depending on things like optimisations etc.
*(address
location) gives the value stored at that location which is being
interpreted as int because of the %d.
*(&ptr2 + 2) is of type int **. That's not the type suitable for the %d
format specifier. As per the standard, it invokes undefined behaviour.
What happens in practise will again vary from implementation to
implementation.
It is a different matter that
the memory layout had the array preceded by the pointer declarations
but apart from that, the print statement is valid. Please correct me
if I am wrong.
The way I view it, the printf call is wrong and the fact that the 'x'
preceded 'ptr' and 'ptr2' in memory has a lot to do with why that
output was printed.
>What you want is:

printf("%d\n", **ptr2);

What part of Sophia's code led you to believe that was what she
wanted?
Not directly. I guessed that she wanted to print the first element
of 'x' using 'ptr2' -- hence the suggestion. Maybe she can clarify.

Jun 27 '08 #18
Sri Harsha Dandibhotla wrote:
On Apr 25, 12:51 pm, sophia <sophia.ag...@gmail.comwrote:
>Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

while others have already talked about the code being broken and
all... and assuming the code works, I think the interviewer assumed
for granted that the stack grows from higher address to low. Now since
both a pointer to an int and a pointer to pointer will have same size
(regulars please correct me if I am wrong on this),
They are allowed to have different sizes and/or representations by the
standard, but you'll struggle to find a system where this is the case.
(&ptr2 + 2) would
point to the memory location after the space for the two pointers.
This happens to be the start of the array in this particular case.
Because the format specified is %d, the compiler considers the integer
value of whatever is present at that location. (I might be very wrong
in this answer, please correct me).
This is a possible explanation and the interviewer would likely have
given it full marks, but it's simply not correct standard C. There are
better ways to explain stack characteristics than with such multiply
broken code.

Jun 27 '08 #19
Ian Collins wrote, On 25/04/08 09:13:
sophia wrote:
>On Apr 25, 12:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
>>sophia wrote:
Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr = x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
Where do people find these contrived examples?

The answer is luck. I just happens that's the way the variables are laid out in memory.
There is something more than luck, that is my conclusion.

I tried changing the value of x[0] to different values but still
it will print the o/p correctly.
The luck is in the memory layout, not the values. The address of &ptr2
+ 2 just happens to be the address of x[0].
True.
>Has it any thing to do with the compiler ?
Everything, memory layout is compiler and platform specific, although
most 32 bit compilers on x86 probably use the same layout.
Hmm. When I run compile it using the 32 bit compiler on this x86 based
machine without specifying any options to gcc I get...
markg@brenda:~$ ./a.out
-1074745616markg@brenda:~$ ./a.out
-1076130400markg@brenda:~$ ./a.out
-1080481408markg@brenda:~$ ./a.out
-1074464160markg@brenda:~$

Note that not only is this *not* an element of x, it is a different
value on consecutive runs.
> I don't have a 64 bit compiler

Every home should have one :)
I have to get my company notebook out if I want a 64 bit compiler.
--
Flash Gordon
The man with two notebooks.
Jun 27 '08 #20
On Apr 26, 12:59 am, santosh <santosh....@gmail.comwrote:
Sri Harsha Dandibhotla wrote:
This is a possible explanation and the interviewer would likely have
given it full marks, but it's simply not correct standard C. There are
better ways to explain stack characteristics than with such multiply
broken code.
I understand that this isn't standard C but I am just trying to see it
from interviewer's viewpoint.
I am a junior at college and I gave an interview for an internship
recently. I was given some broken non standard code which I pointed
out (I lurk quite a bit on this group to identify non standard code to
an extent). He didn't like being corrected and started asking me tough
questions from courses I hadn't yet done).
Moral : Humor the interviewer. :-)
Jun 27 '08 #21
Sri Harsha Dandibhotla wrote:
On Apr 26, 12:59 am, santosh <santosh....@gmail.comwrote:
>Sri Harsha Dandibhotla wrote:
>This is a possible explanation and the interviewer would likely have
given it full marks, but it's simply not correct standard C. There
are better ways to explain stack characteristics than with such
multiply broken code.

I understand that this isn't standard C but I am just trying to see it
from interviewer's viewpoint.
I am a junior at college and I gave an interview for an internship
recently. I was given some broken non standard code which I pointed
out (I lurk quite a bit on this group to identify non standard code to
an extent). He didn't like being corrected and started asking me tough
questions from courses I hadn't yet done).
Moral : Humor the interviewer. :-)
More generally it's indeed a sad necessity to humour ones superiors.

Note that there is nothing wrong with platform specific C, but this
particular example isn't even implementation specific but is likely to
vary across two compilations of the same program.

It's better, IMO, to explain the nature of the hardware stack from a
machine level perspective. C isn't really suitable since it doesn't
require a hardware stack at all. However if you *do* know that your C
implementation uses a hardware stack to store auto objects, then
something like the following program could be used (in a non-conforming
manner of course) to find out the direction of the stack's growth. This
will only work on implementations with linear address spaces.

#include <stdio.h>

#define UP 1
#define DOWN 2
#define UNDEFINED 0
#define RECURSE_DEPTH 3

static void stack_direction(void);

static int r_depth = 0;
static int *addrs[RECURSE_DEPTH];

int main(void)
{
int grows = 0, ctr;

stack_direction();
for (ctr = 0; ctr < RECURSE_DEPTH-1; ctr++) {
if ((void*)addrs[ctr] < (void*)addrs[ctr+1]) grows = UP;
else if ((void*)addrs[ctr] (void*)addrs[ctr+1]) grows = DOWN;
else grows = UNDEFINED;
}
if (grows == UP) puts("Stack grows towards increasing addresses.");
else if (grows == DOWN) puts("Stack grows towards decreasing
addresses.");
else puts("Undefined result.");
return 0;
}

static void stack_direction(void)
{
int iarr[16];
addrs[r_depth++] = &iarr[0];
if (r_depth < RECURSE_DEPTH) stack_direction();
return;
}

Jun 27 '08 #22
Sri Harsha Dandibhotla <ha********@gmail.comwrote:
>
I have a doubt over here(doubt, not question, because I doubt what I
think is true).
You have used "doubt" correctly. Full marks. :-)
I think your reasoning is wrong here. &ptr2 is value
of address type.
C pointers are typed, so it's not just an "address type", it's
specifically a pointer to a pointer to a pointer to an int.
&ptr + 2 is also an address location.
Likewise, it is also a pointer to a pointer to a pointer to an int.
*(address
location) gives the value stored at that location which is being
interpreted as int because of the %d.
The value stored at that location is being interpreted as pointer to a
pointer to an int because that's the type that the pointer being
dereferenced points to. That pointer to a pointer to an int is being
passed to printf. Since %d expects an int argument and the argument
that was passed was not an int, it results in undefined behavior and
thus is not valid.

-Larry Jones

Is it too much to ask for an occasional token gesture of appreciation?!
-- Calvin
Jun 27 '08 #23
On Apr 25, 1:13*pm, Ian Collins <ian-n...@hotmail.comwrote:
sophia wrote:
On Apr 25, 12:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
sophia wrote:
Dear all,
why in the following program
*#include<stdio.h>
*#include<stdlib.h>
*int main(void)
*{
* *int x[] = {99,2,3,4,5};
* *int *ptr,**ptr2;
* *ptr *= x;
* *ptr2 = &ptr;
* *printf("%d",*(&ptr2 + 2));
* *return EXIT_SUCCESS;
*}
printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?
Where do people find these contrived examples?
The answer is luck. *I just happens that's the way the variables are laid out in memory.
There is something more than luck, that is my conclusion.
I tried changing the value of x[0] to different values but still
it will print the o/p correctly.

The luck is in the memory layout, not the values. *The address of &ptr2
+ 2 just happens to be the address of x[0].
but what about this one:-

http://groups.google.co.in/group/com...f?dmode=source
Jun 27 '08 #24
sophia wrote:
On Apr 25, 1:13 pm, Ian Collins <ian-n...@hotmail.comwrote:
>The luck is in the memory layout, not the values. The address of &ptr2
+ 2 just happens to be the address of x[0].

but what about this one:-

http://groups.google.co.in/group/com...f?dmode=source
What about it?

--
Ian Collins.
Jun 27 '08 #25
sophia wrote:
On Apr 25, 1:13*pm, Ian Collins <ian-n...@hotmail.comwrote:
>sophia wrote:
On Apr 25, 12:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
sophia wrote:
Dear all,
why in the following program
#include<stdio.h>
#include<stdlib.h>
int main(void)
{
int x[] = {99,2,3,4,5};
int *ptr,**ptr2;
ptr *= x;
ptr2 = &ptr;
printf("%d",*(&ptr2 + 2));
return EXIT_SUCCESS;
}
printf("%d",*(&ptr2 + 2)); is printing the first element of the
array x ? can anybody explain ?
Where do people find these contrived examples?
>The answer is luck. *I just happens that's the way the variables
are laid out in memory.
There is something more than luck, that is my conclusion.
I tried changing the value of x[0] to different values but still
it will print the o/p correctly.

The luck is in the memory layout, not the values. *The address of
&ptr2 + 2 just happens to be the address of x[0].

but what about this one:-

http://groups.google.co.in/group/com...f?dmode=source
The point that Fred Kleinschmidt was trying to make in that post is that
the output of your program (the one you originally presented) depends
on the relative memory layout of the objects in question. Rearranging
them in their declarations is likely (but not guaranteed) to change
their memory ordering, and hence the program's output. The point is
that the program is broken and whatever it demonstrates can surely be
better explained using other methods.

Jun 27 '08 #26
On Fri, 25 Apr 2008 19:36:12 UTC, Sri Harsha Dandibhotla
<ha********@gmail.comwrote:
On Apr 25, 12:51 pm, sophia <sophia.ag...@gmail.comwrote:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

while others have already talked about the code being broken and
all... and assuming the code works, I think the interviewer assumed
for granted that the stack grows from higher address to low. Now since
both a pointer to an int and a pointer to pointer will have same size
(regulars please correct me if I am wrong on this), (&ptr2 + 2) would
point to the memory location after the space for the two pointers.
No. This is simply going into the lands of undefined behavior.

That is because ptr2 is only a simple, single variable of type pointer
to pointer to int. Getting its address results only into an pointer to
pointer to int, what is not an array again. Adding 2 to it does point
2 pointers to pointer to pointer after the defined location of the
pointer to pointer to pointer to int and as the object pointer to
pointer to pointer to int is not an array it points not to an array
but a plain variable the resulting address is invalid. Dereferencing
an invalid address is undefined behavior and can give anything like a
crash, a random number, letting explode the computer, initiating the
3. world wide war ....... as any undefined behavior can.

Remove the address of operator from the expression and it does what it
should: dereferencing the address of the second member of the array
the pointer to pointer to int points to and giving the ruslult you
wants.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Jun 27 '08 #27
On Sat, 26 Apr 2008 09:15:27 +0000 (UTC), "Herbert Rosenau"
<os****@pc-rosenau.dewrote:
>On Fri, 25 Apr 2008 19:36:12 UTC, Sri Harsha Dandibhotla
<ha********@gmail.comwrote:
>On Apr 25, 12:51 pm, sophia <sophia.ag...@gmail.comwrote:
Dear all,

why in the following program

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

int main(void)
{

int x[] = {99,2,3,4,5};
int *ptr,**ptr2;

ptr = x;
ptr2 = &ptr;

printf("%d",*(&ptr2 + 2));

return EXIT_SUCCESS;
}

printf("%d",*(&ptr2 + 2)); is printing the first element of the array
x ? can anybody explain ?

while others have already talked about the code being broken and
all... and assuming the code works, I think the interviewer assumed
for granted that the stack grows from higher address to low. Now since
both a pointer to an int and a pointer to pointer will have same size
(regulars please correct me if I am wrong on this), (&ptr2 + 2) would
point to the memory location after the space for the two pointers.

No. This is simply going into the lands of undefined behavior.

That is because ptr2 is only a simple, single variable of type pointer
to pointer to int. Getting its address results only into an pointer to
pointer to int, what is not an array again. Adding 2 to it does point
2 pointers to pointer to pointer after the defined location of the
pointer to pointer to pointer to int and as the object pointer to
pointer to pointer to int is not an array it points not to an array
but a plain variable the resulting address is invalid. Dereferencing
an invalid address is undefined behavior and can give anything like a
crash, a random number, letting explode the computer, initiating the
3. world wide war ....... as any undefined behavior can.

Remove the address of operator from the expression and it does what it
should: dereferencing the address of the second member of the array
the pointer to pointer to int points to and giving the ruslult you
wants.
Not quite. Removing the & produces the statement
printf("%d",*(ptr2 + 2));
which still produces undefined behavior. ptr2 is an int**. Adding an
integer to it does not change the type of the expression. The single
dereference produces a value of type int*. This is not the correct
type to pass to printf for the %d. Furthermore, ptr2 points to ptr.
The expression ptr2+2 points to a non-existent int* that would be
located 2*sizeof(int*) bytes beyond ptr. Merely calculating this
address is undefined behavior. Attempting to dereference it is just
icing on the cake.

For the statement to have the intended effect, the & must be replaced
with an * as in
printf("%d",*(*ptr2 + 2));
ptr2 points to ptr. Dereferencing it produces the value of ptr which
is the address of x (or more correctly the address of x[0]). Adding 2
produces the address of x[2] which is then dereferenced to produce the
int 3 which is of the correct type to pass to printf for the %d.
Remove del for email
Jun 27 '08 #28

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

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.