can you tell that y the code is work like that

Discussion in 'C Programming' started by venkatesh, Oct 21, 2005.

  1. venkatesh

    venkatesh Guest

    int *p=20;
    printf("%d",*p);
    printf("%d",p);



    the above code prints the output as
    somegarbage value //for *p(may be address
    20 //for p
    why can you explain
    thanks for that
     
    venkatesh, Oct 21, 2005
    #1
    1. Advertising

  2. venkatesh <> wrote:

    > int *p=20;


    Broken. What makes you suspect that 20 is an appropriate value for a
    pointer to an integer?

    > printf("%d",*p);


    Broken. What exactly do you think a pointer with the value 20 might
    point to?

    > printf("%d",p);


    Broken. The size of a pointer to an integer need not be equal to
    sizeof(int).

    printf( "%p", (void*)p );

    > why can you explain


    Pure random chance, as far as the C standard is concerned.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 21, 2005
    #2
    1. Advertising

  3. venkatesh, le 21/10/2005, a écrit :
    > int *p=20;
    > printf("%d",*p);
    > printf("%d",p);
    >
    >
    >
    > the above code prints the output as
    > somegarbage value //for *p(may be address
    > 20 //for p
    > why can you explain
    > thanks for that


    int dummy = 20;
    int* p = &dummy;
    printf("%d\n",*p);
    printf("%p\n",p);

    or

    int* p = malloc(sizeof int);
    *p = 20;
    printf("%d\n",*p);
    printf("%p\n",p);

    --
    Pierre Maurette
     
    Pierre Maurette, Oct 21, 2005
    #3
  4. venkatesh a écrit :
    > int *p=20;


    This is kinda nonsense. What to you think it meant ?

    The portable way of initializing a pointer to an object are

    - NULL
    - The address of an object of the same type
    - the value returned by malloc()
    - the value returned by fopen() if the type is void* or FILE*
    and similar cases.

    But initialising a pointer with a plain integer is undefined by the
    language. Actually, it may work on a specific platform. It's called an
    implementation-dependent behaviour.

    --
    C is a sharp tool
     
    Emmanuel Delahaye, Oct 21, 2005
    #4
  5. venkatesh

    vire Guest

    yes,
    exactly what you wrote means:
    int* p;
    p = 20;
     
    vire, Oct 21, 2005
    #5
  6. venkatesh

    Default User Guest

    vire wrote:

    > yes,
    > exactly what you wrote means:
    > int* p;
    > p = 20;


    Please read my .sig.


    Brian

    --
    Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header.
     
    Default User, Oct 21, 2005
    #6
  7. Christopher Benson-Manica <> writes:
    > venkatesh <> wrote:
    >> int *p=20;

    >
    > Broken. What makes you suspect that 20 is an appropriate value for a
    > pointer to an integer?


    What's surprising is that his compiler thought it was appropriate.

    A compiler might allow assigning an integer value to a pointer as an
    extension, but if the code is compiled in strict mode (might be called
    "ansi" or "iso", depending on the compiler), the compiler is required
    to issue a diagnostic.

    [...]

    >> printf("%d",p);

    >
    > Broken. The size of a pointer to an integer need not be equal to
    > sizeof(int).


    Size matters not. Using "%d" to print a pointer value invokes
    undefined behavior (though it will often do what you expect anyway).
    It can fail even if int and int* happen to have the same size.

    The correct way to print an int* value is:

    printf("%p", (void*)p);

    Also, the original code, if it doesn't blow up, will probably print
    the values adjacent to each other; you won't be able to tell where one
    ends and the other begins. Rather than

    int *p=20;
    printf("%d",*p);
    printf("%d",p);

    you might try this:

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

    Of course this could still invoke undefined behavior, since (int*)20
    is unlikely to be a valid address.

    Here's a program that actually works:

    #include <stdio.h>
    #include <stdlib.h>
    int main (void)
    {
    int *p = malloc(sizeof *p);
    if (p == NULL) {
    printf("malloc failed\n");
    }
    else {
    *p = 20;
    printf("*p = %d\n", *p);
    printf("p = %p\n", (void*)p);
    }
    return 0;
    }

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 21, 2005
    #7
  8. Keith Thompson <> wrote:

    > The correct way to print an int* value is:


    > printf("%p", (void*)p);


    (which I did mention, FWIW)

    > Of course this could still invoke undefined behavior, since (int*)20
    > is unlikely to be a valid address.


    Is it not UB regardless, since 20 is not a value obtained from
    malloc()?

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 21, 2005
    #8
  9. venkatesh

    Tim Rentsch Guest

    Emmanuel Delahaye <> writes:

    > venkatesh a écrit :
    > > int *p=20;

    >
    > This is kinda nonsense. What to you think it meant ?
    >
    > The portable way of initializing a pointer to an object are
    >
    > - NULL
    > - The address of an object of the same type
    > - the value returned by malloc()
    > - the value returned by fopen() if the type is void* or FILE*
    > and similar cases.


    And 0 (or any 0-valued constant expression).


    > But initialising a pointer with a plain integer is undefined by the
    > language.


    Unless the integer is 0.
     
    Tim Rentsch, Oct 21, 2005
    #9
  10. Christopher Benson-Manica <> writes:
    > Keith Thompson <> wrote:
    >> The correct way to print an int* value is:

    >
    >> printf("%p", (void*)p);

    >
    > (which I did mention, FWIW)


    Ok.

    >> Of course this could still invoke undefined behavior, since (int*)20
    >> is unlikely to be a valid address.

    >
    > Is it not UB regardless, since 20 is not a value obtained from
    > malloc()?


    Valid pointers don't have to be obtained from malloc().

    The conversion itself yields an implementation-defined result:

    An integer may be converted to any pointer type. Except as
    previously specified, the result is implementation-defined, might
    not be correctly aligned, might not point to an entity of the
    referenced type, and might be a trap representation.

    with a footnote:

    The mapping functions for converting a pointer to an integer or an
    integer to a pointer are intended to be consistent with the
    addressing structure of the execution environment.

    If the result happens to be an invalid pointer, dereferencing it
    invokes undefined behavior. If the implementation happens to
    guarantee that 20 is a valid address for an int, the behavior of
    dereferencing (int*)20 is merely implementation-defined.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 21, 2005
    #10
  11. Tim Rentsch a écrit :
    >>The portable way of initializing a pointer to an object are
    >>
    >>- NULL

    <...>
    > And 0 (or any 0-valued constant expression).


    > Unless the integer is 0.


    NULL was supposed to cover the case...

    --
    C is a sharp tool
     
    Emmanuel Delahaye, Oct 22, 2005
    #11
  12. venkatesh

    Tim Rentsch Guest

    Emmanuel Delahaye <> writes:

    > Tim Rentsch a écrit :
    > >>The portable way of initializing a pointer to an object are
    > >>
    > >>- NULL

    > <...>
    > > And 0 (or any 0-valued constant expression).

    >
    > > Unless the integer is 0.

    >
    > NULL was supposed to cover the case...


    I guessed that might have been the intention; however,
    NULL is not guaranteed to be 0, and typically in fact
    it isn't.
     
    Tim Rentsch, Oct 26, 2005
    #12
  13. venkatesh

    Jordan Abel Guest

    On 2005-10-26, Tim Rentsch <> wrote:
    > Emmanuel Delahaye <> writes:
    >
    >> Tim Rentsch a écrit :
    >> >>The portable way of initializing a pointer to an object are
    >> >>
    >> >>- NULL

    >> <...>
    >> > And 0 (or any 0-valued constant expression).

    >>
    >> > Unless the integer is 0.

    >>
    >> NULL was supposed to cover the case...

    >
    > I guessed that might have been the intention; however,
    > NULL is not guaranteed to be 0, and typically in fact
    > it isn't.


    It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
    might be ((void *)0) or something like that, but i very much doubt anyone has
    it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
    become 0 when converted to an integer
     
    Jordan Abel, Oct 26, 2005
    #13
  14. Jordan Abel <> writes:
    > On 2005-10-26, Tim Rentsch <> wrote:

    [...]
    >> I guessed that might have been the intention; however,
    >> NULL is not guaranteed to be 0, and typically in fact
    >> it isn't.

    >
    > It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
    > might be ((void *)0) or something like that, but i very much doubt anyone has
    > it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
    > become 0 when converted to an integer


    No, I don't believe it is.

    If NULL is defined as 0, then of course it's already of type int. But
    if NULL is defined as (void*)0, then it's an expression of type void*,
    and there's no guarantee that converting it to int will yield the
    value 0.

    The only specific guarantee is that a null pointer constant converted
    to a pointer type yields a null pointer, and that only applies at
    compilation time.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 26, 2005
    #14
  15. venkatesh

    Jordan Abel Guest

    On 2005-10-26, Keith Thompson <> wrote:
    > Jordan Abel <> writes:
    >> On 2005-10-26, Tim Rentsch <> wrote:

    > [...]
    >>> I guessed that might have been the intention; however,
    >>> NULL is not guaranteed to be 0, and typically in fact
    >>> it isn't.

    >>
    >> It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
    >> might be ((void *)0) or something like that, but i very much doubt anyone has
    >> it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
    >> become 0 when converted to an integer

    >
    > No, I don't believe it is.
    >
    > If NULL is defined as 0, then of course it's already of type int.
    > But if NULL is defined as (void*)0, then it's an expression of
    > type void*, and there's no guarantee that converting it to int
    > will yield the value 0.


    I could have sworn that there was a guarantee that null pointers
    (constant or otherwise) convert to zero

    how does if(p) work, then? if(p != 0) can be explained by the 0
    being converted to a null pointer, and !p is defined as 0==p but i
    could have sworn the argument in a conditional had to be an integer
    type

    > The only specific guarantee is that a null pointer constant
    > converted to a pointer type yields a null pointer, and that only
    > applies at compilation time.


    actually, though i could find nothing supporting my belief about
    conversions to integer, apparently (from my interpretation)
    conversions from any null pointer to any pointer type [at least, any
    that the original pointer type is allowed to be converted to - void
    pointer and pointer types with 'less strict alignment'] yield a null
    pointer - constant or otherwise. It doesn't actually say that, but
    you can get as far as "will compare equal [with the original null
    pointer]" from other statements, and it seems implied that any
    pointer that will compare equal with a null pointer is a null
    pointer.
     
    Jordan Abel, Oct 26, 2005
    #15
  16. venkatesh

    Tim Rentsch Guest

    Jordan Abel <> writes:

    > On 2005-10-26, Tim Rentsch <> wrote:
    > > Emmanuel Delahaye <> writes:
    > >
    > >> Tim Rentsch a écrit :
    > >> >>The portable way of initializing a pointer to an object are
    > >> >>
    > >> >>- NULL
    > >> <...>
    > >> > And 0 (or any 0-valued constant expression).
    > >>
    > >> > Unless the integer is 0.
    > >>
    > >> NULL was supposed to cover the case...

    > >
    > > I guessed that might have been the intention; however,
    > > NULL is not guaranteed to be 0, and typically in fact
    > > it isn't.

    >
    > It's not guaranteed to be all-bits-zero, but that's not what he claimed. It
    > might be ((void *)0) or something like that, but i very much doubt anyone has
    > it as ((void *)0xdeadbeef), especially given that NULL _is_ guaranteed to
    > become 0 when converted to an integer


    I didn't say anything about all-bits-zero. NULL usually is something
    other than 0 (even if it compares equal to 0), but 0 always works in
    initializing a pointer variable, so I thought it should be mentioned
    in addition to mentioning NULL.

    Also using 0 rather than NULL can be done without having to #include
    anything. That's clearly a way that 0 and NULL are different.
     
    Tim Rentsch, Oct 26, 2005
    #16
  17. venkatesh

    Richard Bos Guest

    Jordan Abel <> wrote:

    > I could have sworn that there was a guarantee that null pointers
    > (constant or otherwise) convert to zero


    Nope. Constant zeroes convert to null pointers; the other way 'round is
    common, but not guaranteed.

    > how does if(p) work, then? if(p != 0) can be explained by the 0
    > being converted to a null pointer, and !p is defined as 0==p but i
    > could have sworn the argument in a conditional had to be an integer
    > type


    You would have perjured yourself. "The controlling expression of an if
    statement shall have scalar type" is all the Standard has to say about
    it. Well, that, and that the path taken depends on whether said
    expression compares equal to 0.

    Richard
     
    Richard Bos, Oct 26, 2005
    #17
  18. venkatesh

    Default User Guest

    Tim Rentsch wrote:


    > I didn't say anything about all-bits-zero. NULL usually is something
    > other than 0 (even if it compares equal to 0), but 0 always works in
    > initializing a pointer variable, so I thought it should be mentioned
    > in addition to mentioning NULL.



    Do you have some evidence for "usually something other than 0"?



    Brian
     
    Default User, Oct 26, 2005
    #18
  19. venkatesh

    Tim Rentsch Guest

    "Default User" <> writes:

    > Tim Rentsch wrote:
    >
    >
    > > I didn't say anything about all-bits-zero. NULL usually is something
    > > other than 0 (even if it compares equal to 0), but 0 always works in
    > > initializing a pointer variable, so I thought it should be mentioned
    > > in addition to mentioning NULL.

    >
    >
    > Do you have some evidence for "usually something other than 0"?


    Only a personal informal survey. If someone has more extensive
    data to report, I'd be interested to hear about (whether it
    agrees with mine or not).
     
    Tim Rentsch, Oct 26, 2005
    #19
  20. venkatesh

    Default User Guest

    Tim Rentsch wrote:

    > "Default User" <> writes:


    > > Do you have some evidence for "usually something other than 0"?

    >
    > Only a personal informal survey. If someone has more extensive
    > data to report, I'd be interested to hear about (whether it
    > agrees with mine or not).


    My two data points are the VC++ 6.0 and gcc 3.3.1 on Solaris, which
    both give an all-bits-zero null pointer.

    Note that this doesn't have anything to do with the standard language
    at all. It's been my impression from previous discussion that some non
    0 null pointers exist, but that they were in the minority.



    Brian
     
    Default User, Oct 26, 2005
    #20
    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. Richard Dixson
    Replies:
    1
    Views:
    514
    Joe Fallon
    May 18, 2004
  2. Miguel Dias Moura
    Replies:
    2
    Views:
    342
    Martin
    Jun 22, 2004
  3. yogesh
    Replies:
    1
    Views:
    367
    Victor Bazarov
    Mar 14, 2007
  4. Replies:
    5
    Views:
    98
    apatheticagnostic
    May 8, 2008
  5. johannes falcone
    Replies:
    6
    Views:
    995
    johannes falcone
    May 16, 2013
Loading...

Share This Page