pointer dereference

[somenath]

Hi All ,
I have some doubts fro the following program.

#include<stdio.h>

int main(void)
{
char **p = 0;
printf("%d\n", ++p);
return 0;
}

The Output of the program is
4
Could any body let me know how it prints 4?
Regards ,
Somanath

 

[yifanernei]

p is a point, pointed to type "char*"
"++p" move sizeof(char *) bytes

 

[Richard]

Hi All ,
I have some doubts fro the following program.

#include<stdio.h>

int main(void)
{
char **p = 0;
printf("%d\n", ++p);
return 0;
}

The Output of the program is
4
Could any body let me know how it prints 4?
Regards ,
Somanath

You will probably get a lot of clever answers, but I suspect you mean
"why it prints 4"?

Look carefully at this line:

printf("%d\n", ++p);

What does %d mean? Look it up.

What is p? p is a pointer to a char pointer. What does ++p do? It makes
p point to the NEXT char pointer. How long is a char pointer on your
machine? Probably 32 bits or 4 bytes.

So, if p was 0, then making it point to the NEXT pointer stored in
memory adds 4 to its value.

0+4=4.

As usual with this type of level, play around in a debugger and it will
all become clear.

 

[pete]

Hi All ,
I have some doubts fro the following program.

#include<stdio.h>

int main(void)
{
char **p = 0;
printf("%d\n", ++p);
return 0;
}

The Output of the program is
4
Could any body let me know how it prints 4?

Sheer luck.
p is initialised as a null pointer.
(1 + NULL) is undefined.
Printing the value of a pointer type by using %d,
is also undefined.

 

[Mark Bluemel]

Hi All ,
I have some doubts fro the following program.

Not unreasonably. It's so horrid...

#include<stdio.h>

int main(void)
{
char **p = 0;

p is a pointer to pointer to char.
p is initialised to a null pointer. (Note that the internal
representation of a null pointer is not guaranteed to be all zeroes)

printf("%d\n", ++p);

You increment p, moving it on by the size of a pointer to char.

You then lie to printf telling it you are passing an int.

return 0;
}

The Output of the program is
4
Could any body let me know how it prints 4?

The machine appears to
a) have a flat address space
b) represent pointers in a compatible form to ints
c) represent a null pointer as all zeroes
d) allow incrementing a null pointer
e) have 4-"cell" pointers to char

None of the above are guaranteed to be true.

 

[CBFalconer]

I have some doubts fro the following program.

#include<stdio.h>

int main(void)
{
char **p = 0;
printf("%d\n", ++p);
return 0;
}

The Output of the program is
4
Could any body let me know how it prints 4?

It can print anything it desires, or explode. All these are
satisfactory examples of the undefined behaviour it exhibits. A
pointer is not a signed integer.

 

[Charles Richmond]

It can print anything it desires, or explode. All these are
satisfactory examples of the undefined behaviour it exhibits. A
pointer is not a signed integer.

But since this program displays undefined behavior, it
has some probability, *no* matter how infinitesimal that
probability may be, of doing exactly what the programmer
wants. ;-)

This is the only chance that programmers have... who know
so little about C. (Slim and none, and Slim just left town.)

 

[Ravishankar S]

Hi,

on a 32 bit machine all "pointer" vars are 32 bits (or 4 bytes). So a
"pointer to pointer" will always be incremented by 4 (pointer arithmetic
says that pointer is incremented by size the "type pointed to"). We can
also generalise that all pointers to pointer and pointers to pointers to
pointers and so will always be incremented by sizeof(pointer type) on that
machine.

Regards,
Ravishankar

 

[Flash Gordon]

Ravishankar S wrote, On 10/08/07 09:59:

Please do not top-post, your reply belongs under or intermixed with the
text you are replying to. See almost all posts in this group for examples.

on a 32 bit machine all "pointer" vars are 32 bits (or 4 bytes).

Define a 32 bit machine. Address, databus, registers and ALU are not
always all the same size. Many compilers used on the 80386DX (which
Intel said was a 32 bit processor) used 16 bit pointers. Other
processors have a 32 bit byte, so a 32 bit int is 1 byte.

> So a
"pointer to pointer" will always be incremented by 4

See above for why this may not be true.

> (pointer arithmetic
says that pointer is incremented by size the "type pointed to").

This is true.

> We can
also generalise that all pointers to pointer and pointers to pointers to
pointers and so will always be incremented by sizeof(pointer type) on that
machine.

This is more specific than your previous statement!

<snip material that was being replied to.>

 

[santosh]

Ravishankar S wrote:

[Please don't top post]

Hi,

on a 32 bit machine all "pointer" vars are 32 bits (or 4 bytes).

This is not guaranteed, though I don't know of a contrary case.

So a "pointer to pointer" will always be incremented by 4

Four bytes, not just four. Major difference.

 

[CBFalconer]

on a 32 bit machine all "pointer" vars are 32 bits (or 4 bytes).
So a "pointer to pointer" will always be incremented by 4 (pointer
arithmetic says that pointer is incremented by size the "type
pointed to"). We can also generalise that all pointers to pointer
and pointers to pointers to pointers and so will always be
incremented by sizeof(pointer type) on that machine.

Your basic premise is wrong. There is no correlation between the
addressing size and the size of a pointer, although they may happen
to coincide. Just as one possible example, consider a system where
heap allocation (via malloc/realloc) is entirely separate, and all
such pointers need to be identified by an extra bit.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

 

[Richard]

Your basic premise is wrong. There is no correlation between the
addressing size and the size of a pointer, although they may happen
to coincide. Just as one possible example, consider a system where
heap allocation (via malloc/realloc) is entirely separate, and all
such pointers need to be identified by an extra bit.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

Are you aware that you are posting with two signature lines? This has
been mentioned before since it stops my newsreader correctly clipping
your signature as the context above shows. Since your second signature
is inserted by teranews you should either remove your other signature or
considering moving to another free nntp server such as news.aioe.org.

 

[Martin Ambuhl]

Hi,

on a 32 bit machine all "pointer" vars are 32 bits (or 4 bytes).

There is no reason to think that pointers are 32 bits on a 32 bit machine.

There is no reason to think that a 32 bit machine has octets for bytes.

That these things are true on the implementations you know dees not
warrant your assertions.

So a
"pointer to pointer" will always be incremented by 4 (pointer arithmetic
says that pointer is incremented by size the "type pointed to").

The number 4 depends on particulars of an implementation.
More properly, for any type T
T *a;
if a is incremented, it is by sizeof(T);

For
T **b;
Incrementing b is by the size of the type of *b, namely sizeof(T *)

> We can
also generalise that all pointers to pointer and pointers to pointers to
pointers and so will always be incremented by sizeof(pointer type) on that
machine.

That's a form of question begging. You have used the correct premise as
the conclusion, even though what you used as the premise is wrong.