pointer dereference

Discussion in 'C Programming' started by somenath, Aug 9, 2007.

  1. somenath

    somenath Guest

    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
     
    somenath, Aug 9, 2007
    #1
    1. Advertising

  2. somenath

    yifanernei Guest

    p is a point, pointed to type "char*"
    "++p" move sizeof(char *) bytes
     
    yifanernei, Aug 9, 2007
    #2
    1. Advertising

  3. somenath

    Richard Guest

    somenath <> writes:

    > 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.
     
    Richard, Aug 9, 2007
    #3
  4. somenath

    pete Guest

    somenath wrote:
    >
    > 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.

    --
    pete
     
    pete, Aug 9, 2007
    #4
  5. somenath

    Mark Bluemel Guest

    somenath wrote:
    > 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.
     
    Mark Bluemel, Aug 9, 2007
    #5
  6. somenath

    CBFalconer Guest

    somenath wrote:
    >
    > 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.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 9, 2007
    #6
  7. CBFalconer wrote:
    > somenath wrote:
    >> 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.
    >


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

    --
    +----------------------------------------------------------------+
    | Charles and Francis Richmond richmond at plano dot net |
    +----------------------------------------------------------------+
     
    Charles Richmond, Aug 9, 2007
    #7
  8. 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



    "somenath" <> wrote in message
    news:...
    > 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
    >
     
    Ravishankar S, Aug 10, 2007
    #8
  9. somenath

    Flash Gordon Guest

    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.>
    --
    Flash Gordon
     
    Flash Gordon, Aug 10, 2007
    #9
  10. somenath

    santosh Guest

    Ravishankar S wrote:

    [Please don't top post]

    > "somenath" <> wrote in message
    > news:...
    >> 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?


    > 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.
     
    santosh, Aug 10, 2007
    #10
  11. somenath

    CBFalconer Guest

    Ravishankar S wrote:
    >
    > 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)



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 10, 2007
    #11
  12. somenath

    Richard Guest

    CBFalconer <> writes:

    > Ravishankar S wrote:
    >>
    >> 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)



    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.
     
    Richard, Aug 10, 2007
    #12
  13. Ravishankar S wrote:
    > 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.
     
    Martin Ambuhl, Aug 10, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Denis Palmeiro

    NULL Pointer Dereference

    Denis Palmeiro, Jul 8, 2003, in forum: C Programming
    Replies:
    10
    Views:
    680
    Shill
    Jul 16, 2003
  2. Replies:
    9
    Views:
    562
    Bo Persson
    Feb 11, 2006
  3. somenath

    pointer dereference

    somenath, Jul 12, 2007, in forum: C Programming
    Replies:
    34
    Views:
    943
    Anurag
    Jul 18, 2007
  4. Nyang A. Phra

    Function pointer dereference security

    Nyang A. Phra, Nov 11, 2007, in forum: C Programming
    Replies:
    0
    Views:
    302
    Nyang A. Phra
    Nov 11, 2007
  5. Nyang A. Phra

    Function pointer dereference security

    Nyang A. Phra, Nov 11, 2007, in forum: C Programming
    Replies:
    13
    Views:
    780
    Kevin D. Quitt
    Dec 20, 2007
Loading...

Share This Page