passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

Discussion in 'C Programming' started by jimjim, Mar 25, 2006.

  1. jimjim

    jimjim Guest

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

    //WARNING: The function's signature should be: f( int ** )
    void f(int *ip) {
    static int dummy = 5;
    *ip = &dummy;
    }

    int main(){
    int *ip;
    f(&ip);
    printf("%d",*ip);
    return 0;
    }

    The function's signature should be: f( int ** ). However, f( int *) seems to
    produce the same results, even though I am
    warned by the compiler (Borland_bcc_5.5):
    Warning W8069 solution.c 5: Nonportable pointer conversion in function f
    Warning W8075 solution.c 12: Suspicious pointer conversion in function main

    What can go wrong when you pass the address of a pointer to a function that
    does not recieve a pointer to a pointer?

    TIA
    jimjim
    jimjim, Mar 25, 2006
    #1
    1. Advertising

  2. jimjim

    Michael Mair Guest

    Re: passing the address of a pointer to a func that doesnt recievea pointer-to-a-pointer

    jimjim schrieb:
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > //WARNING: The function's signature should be: f( int ** )
    > void f(int *ip) {
    > static int dummy = 5;
    > *ip = &dummy;
    > }
    >
    > int main(){
    > int *ip;
    > f(&ip);
    > printf("%d",*ip);
    > return 0;
    > }
    >
    > The function's signature should be: f( int ** ). However, f( int *) seems to
    > produce the same results, even though I am
    > warned by the compiler (Borland_bcc_5.5):
    > Warning W8069 solution.c 5: Nonportable pointer conversion in function f
    > Warning W8075 solution.c 12: Suspicious pointer conversion in function main
    >
    > What can go wrong when you pass the address of a pointer to a function that
    > does not recieve a pointer to a pointer?


    The above seems to "work" by pure, dumb luck or bad luck.
    It works, if
    1) the representation of an int** is the same as for an int*
    2) the conversion address->int->address yields the original
    address
    3) an int* can be stored in an int (this can hold if the size
    of an int* is the same as the size of an int).
    This is just a rough description, not by the very word of the
    standard. This means, it can easily break or sometimes break
    if sizeof (int*) != sizeof (int) which is not that unlikely
    in the future if you think of 64 bit architectures.

    Just do not do that.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Mar 25, 2006
    #2
    1. Advertising

  3. jimjim

    pete Guest

    jimjim wrote:

    > What can go wrong when you pass
    > the address of a pointer to a function that
    > does not recieve a pointer to a pointer?


    Whatever might be caused by the function translation
    not taking into consideration that you may have
    passed in the wrong type.

    The philosophy of the newsgroup,
    is that it is worth knowing how to write defined code,
    and not worth knowing just exactly
    what might happen with undefined code.

    --
    pete
    pete, Mar 25, 2006
    #3
  4. On Sat, 25 Mar 2006 11:37:40 GMT, "jimjim" <>
    wrote:

    >#include <stdio.h>
    >#include <stdlib.h>
    >
    >//WARNING: The function's signature should be: f( int ** )
    >void f(int *ip) {
    >static int dummy = 5;
    >*ip = &dummy;


    As a result of the faulty calling statement, this statement invokes
    undefined behavior. One of the more insidious manifestations of
    undefined behavior is to "appear to work as intended." Just bad luck.
    Not the worst luck (it could have formatted your hard drive) or good
    luck (an easily diagnosed software failure).

    >}
    >
    >int main(){
    >int *ip;
    >f(&ip);
    >printf("%d",*ip);
    >return 0;
    >}
    >
    >The function's signature should be: f( int ** ). However, f( int *) seems to
    >produce the same results, even though I am
    >warned by the compiler (Borland_bcc_5.5):
    >Warning W8069 solution.c 5: Nonportable pointer conversion in function f
    >Warning W8075 solution.c 12: Suspicious pointer conversion in function main


    Ignore the warnings if you want but you really need to understand ALL
    the repercussions.

    >
    >What can go wrong when you pass the address of a pointer to a function that
    >does not recieve a pointer to a pointer?
    >

    Let's just consider your code and a system that requires an int to be
    aligned on a four-byte boundary. When you return from f, ip contains
    the address 5. Your printf statement says go to address 5 and extract
    the value of the int that is there. What will the hardware do when it
    attempts to extract an int that is not aligned properly.

    What about systems where an int and an address do not share the same
    representation. If you code something like
    int *ptr;
    ptr = (int*)dummy;
    the compiler knows you are converting an int to a pointer and can
    generate the code to to perform the conversion properly. In your
    code, the compiler believes you assigning an int value to an int and
    sees no need for any conversion. The value in ip might be a trap
    representation (that would be good luck).


    Remove del for email
    Barry Schwarz, Mar 25, 2006
    #4
  5. jimjim

    SM Ryan Guest

    # What can go wrong when you pass the address of a pointer to a function that
    # does not recieve a pointer to a pointer?

    You can use any type T for int* such that sizeof(T)=sizeof(int*). If you cast,
    you will avoid compiler warnings.

    On most implementations sizeof(int)=sizeof(T*) and in the early days of
    unix many interfaces were based on that. If you need to do this, and this
    is not just stupid C pet tricks, be sure to test to sizeof assumption in
    main() start up or in the installer.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    Wow. A sailboat.
    SM Ryan, Mar 26, 2006
    #5
  6. Re: passing the address of a pointer to a func that doesnt recievea pointer-to-a-pointer

    SM Ryan <> writes:
    > # What can go wrong when you pass the address of a pointer to a function
    > # that does not recieve a pointer to a pointer?


    The question was posted by "jimjim" <>.
    Please don't snip attributions. And *please* stop using your stupid
    '#' quoting character. You've been told repeatedly that it causes
    problems for some newsreaders; your stubbornness on this point is why
    I usually ignore anything you post.

    > You can use any type T for int* such that sizeof(T)=sizeof(int*). If
    > you cast, you will avoid compiler warnings.
    >
    > On most implementations sizeof(int)=sizeof(T*) and in the early days of
    > unix many interfaces were based on that. If you need to do this, and this
    > is not just stupid C pet tricks, be sure to test to sizeof assumption in
    > main() start up or in the installer.


    Casting to suppress compiler warnings is dangerous and foolish.
    Parameters of different types can be passed by different mechanisms,
    even if they're the same size. For example, some systems might use
    different sets of registers for pointers vs. integers, or integers
    vs. floating-point types. If both types are pointers, there's
    probably less risk of something going visibly wrong, but the behavior
    is still undefined. Don't waste time figuring out how it can go
    wrong; just fix the code.

    --
    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, Mar 26, 2006
    #6
  7. jimjim

    CBFalconer Guest

    Re: passing the address of a pointer to a func that doesnt recieveapointer-to-a-pointer

    Keith Thompson wrote:
    > SM Ryan <> writes:
    >
    >># What can go wrong when you pass the address of a pointer to a
    >># function that does not recieve a pointer to a pointer?

    >
    > The question was posted by "jimjim" <>.
    > Please don't snip attributions. And *please* stop using your
    > stupid '#' quoting character. You've been told repeatedly that
    > it causes problems for some newsreaders; your stubbornness on
    > this point is why I usually ignore anything you post.


    Many of us no longer notice him, we just let the plonk file work.

    --
    Some informative links:
    news:news.announce.newusers
    http://www.geocities.com/nnqweb/
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.caliburn.nl/topposting.html
    http://www.netmeister.org/news/learn2quote.html
    CBFalconer, Mar 26, 2006
    #7
  8. jimjim

    jimjim Guest

    >> What can go wrong when you pass the address of a pointer to a function
    >> that does not recieve a pointer to a pointer?

    >
    > The above seems to "work" by pure, dumb luck or bad luck.
    > It works, if
    > 1) the representation of an int** is the same as for an int*
    > 2) the conversion address->int->address yields the original
    > address
    > 3) an int* can be stored in an int (this can hold if the size
    > of an int* is the same as the size of an int).
    > This is just a rough description, not by the very word of the
    > standard. This means, it can easily break or sometimes break
    > if sizeof (int*) != sizeof (int) which is not that unlikely
    > in the future if you think of 64 bit architectures.
    >

    Hi..thx to all for your replies!

    As far as your (1) point is concerned, I understand it.
    Now, your (2) point hints that theres a relationship btw pointer
    representation of an address and int(s). Can you elaborate on that, please?
    Regarding your (3) point, how does an int* and an int relates to my code's
    use of an int* as an int**? Can you elaborate, please?

    TIA
    jimjim, Mar 26, 2006
    #8
  9. jimjim opined:

    >>> What can go wrong when you pass the address of a pointer to a
    >>> function that does not recieve a pointer to a pointer?

    >>
    >> The above seems to "work" by pure, dumb luck or bad luck.
    >> It works, if
    >> 1) the representation of an int** is the same as for an int*
    >> 2) the conversion address->int->address yields the original
    >> address
    >> 3) an int* can be stored in an int (this can hold if the size
    >> of an int* is the same as the size of an int).
    >> This is just a rough description, not by the very word of the
    >> standard. This means, it can easily break or sometimes break
    >> if sizeof (int*) != sizeof (int) which is not that unlikely
    >> in the future if you think of 64 bit architectures.
    >>

    > Hi..thx to all for your replies!
    >
    > As far as your (1) point is concerned, I understand it.
    > Now, your (2) point hints that theres a relationship btw pointer
    > representation of an address and int(s). Can you elaborate on that,


    2) says that your code will work if converting from the pointer to
    `int` and back to the pointer, yields the same pointer you started
    with. This is going to be implementation-specific, so you can't really
    count on that being true.

    > please? Regarding your (3) point, how does an int* and an int relates
    > to my code's use of an int* as an int**? Can you elaborate, please?


    It would be possible to reply to that, but you did not quote the code
    in question, and I can't see your OP. You also snipped attribution
    lines (the ones saying "jimjim opined:" or similar), soI don't really
    know who you're replying to.

    > TIA


    These have been slated recently, and for good reasons, IMHO.

    --
    BR, Vladimir

    Theory is gray, but the golden tree of life is green.
    -- Goethe
    Vladimir S. Oka, Mar 26, 2006
    #9
  10. jimjim

    santosh Guest

    Vladimir S. Oka wrote:
    > jimjim opined:
    > > please? Regarding your (3) point, how does an int* and an int relates
    > > to my code's use of an int* as an int**? Can you elaborate, please?

    >
    > It would be possible to reply to that, but you did not quote the code
    > in question, and I can't see your OP. You also snipped attribution
    > lines (the ones saying "jimjim opined:" or similar), soI don't really
    > know who you're replying to.


    Here's a reconstruction of the thread, as far as I can see:

    > jimjim wrote:
    >> Michael Mair wrote:
    >> jimjim schrieb:
    >>> #include <stdio.h>
    >>> #include <stdlib.h>
    >>>
    >>> //WARNING: The function's signature should be: f( int ** )
    >>> void f(int *ip) {
    >>> static int dummy = 5;
    >>> *ip = &dummy;
    >>> }
    >>>
    >>> int main(){
    >>> int *ip;
    >>> f(&ip);
    >>> printf("%d",*ip);
    >>> return 0;
    >>> }
    >>>
    >>> The function's signature should be: f( int ** ). However, f( int *) seems to
    >>> produce the same results, even though I am
    >>> warned by the compiler (Borland_bcc_5.5):
    >>> Warning W8069 solution.c 5: Nonportable pointer conversion in function f
    >>> Warning W8075 solution.c 12: Suspicious pointer conversion in function main
    >>>
    >>> What can go wrong when you pass the address of a pointer to a function that
    >>> does not recieve a pointer to a pointer?

    >>
    >> The above seems to "work" by pure, dumb luck or bad luck.
    >> It works, if
    >> 1) the representation of an int** is the same as for an int*
    >> 2) the conversion address->int->address yields the original
    >> address
    >> 3) an int* can be stored in an int (this can hold if the size
    >> of an int* is the same as the size of an int).
    >> This is just a rough description, not by the very word of the
    >> standard. This means, it can easily break or sometimes break
    >> if sizeof (int*) != sizeof (int) which is not that unlikely
    >> in the future if you think of 64 bit architectures.
    >>
    >> Just do not do that.

    > Hi..thx to all for your replies!
    >
    > As far as your (1) point is concerned, I understand it.
    > Now, your (2) point hints that theres a relationship btw pointer
    > representation of an address and int(s). Can you elaborate on that, please?
    > Regarding your (3) point, how does an int* and an int relates to my code's
    > use of an int* as an int**? Can you elaborate, please?
    >
    > TIA
    santosh, Mar 26, 2006
    #10
  11. jimjim

    SM Ryan Guest

    Re: passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

    # The question was posted by "jimjim" <>.
    # Please don't snip attributions. And *please* stop using your stupid
    # '#' quoting character. You've been told repeatedly that it causes
    # problems for some newsreaders; your stubbornness on this point is why
    # I usually ignore anything you post.

    Now I'm scared. Please, please, don't netkop me.

    # Casting to suppress compiler warnings is dangerous and foolish.
    # Parameters of different types can be passed by different mechanisms,
    # even if they're the same size. For example, some systems might use
    # different sets of registers for pointers vs. integers, or integers

    If your compiler is incapable of moving values into correct registers
    during a cast, you desperately need a new compiler.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    This is one wacky game show.
    SM Ryan, Mar 27, 2006
    #11
  12. jimjim

    santosh Guest

    SM Ryan wrote:
    >> The question was posted by "jimjim" <>.
    >> Please don't snip attributions. And *please* stop using your stupid
    >> '#' quoting character. You've been told repeatedly that it causes
    >> problems for some newsreaders; your stubbornness on this point is why
    >> I usually ignore anything you post.

    >
    > Now I'm scared. Please, please, don't netkop me.
    >
    >> Casting to suppress compiler warnings is dangerous and foolish.
    >> Parameters of different types can be passed by different mechanisms,
    >> even if they're the same size. For example, some systems might use
    >> different sets of registers for pointers vs. integers, or integers

    >
    > If your compiler is incapable of moving values into correct registers
    > during a cast, you desperately need a new compiler.


    The whole point of a cast is to force a compiler to do what you want it
    to do, in which case it might very well end up storing values in
    registers not suited for their types, and giving rise to undefined
    behaviour. That is why it's advisable to use a cast only after
    understanding the ramifications, (which might mean looking up
    implementation specific behaviour), and when it's use is essential to
    the code in question.
    santosh, Mar 27, 2006
    #12
  13. Re: passing the address of a pointer to a func that doesnt recievea pointer-to-a-pointer

    SM Ryan <> writes:
    [...]
    > > Casting to suppress compiler warnings is dangerous and foolish.
    > > Parameters of different types can be passed by different mechanisms,
    > > even if they're the same size. For example, some systems might use
    > > different sets of registers for pointers vs. integers, or integers

    >
    > If your compiler is incapable of moving values into correct registers
    > during a cast, you desperately need a new compiler.


    Ok, the differences in parameter passing applies mostly in cases where
    a call is performed with no prototype in scope.

    The original code has a function that takes a parameter of type int*,
    and calls it with an argument of type int**. The compiler quite
    correctly complained (it's a constraint violation, so it's required to
    do so).

    The solution is to fix either the function or the call so the types
    are consistent. Casting the int** argument to int* will (probably)
    silence the warning, and won't cause problems with parameter passing
    mechanisms. The only problem is that the result of converting the
    int** value to int* is unlikely to be meaningful.

    The OP asked what can go wrong; you advised him to hide the problem
    with a meaningless cast.

    --
    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, Mar 27, 2006
    #13
  14. Re: passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

    "SM Ryan" <> wrote in
    message news:...
    > # The question was posted by "jimjim" <>.
    > # Please don't snip attributions. And *please* stop using your stupid
    > # '#' quoting character. You've been told repeatedly that it causes
    > # problems for some newsreaders; your stubbornness on this point is why
    > # I usually ignore anything you post.
    >
    > Now I'm scared. Please, please, don't netkop me.
    >


    Keith. How can you criticize him for "#" when you use "]" on occasion?
    Rod Pemberton, Mar 27, 2006
    #14
  15. Re: passing the address of a pointer to a func that doesnt recievea pointer-to-a-pointer

    "Rod Pemberton" <> writes:
    > "SM Ryan" <> wrote in
    > message news:...
    >> # The question was posted by "jimjim" <>.
    >> # Please don't snip attributions. And *please* stop using your stupid
    >> # '#' quoting character. You've been told repeatedly that it causes
    >> # problems for some newsreaders; your stubbornness on this point is why
    >> # I usually ignore anything you post.
    >>
    >> Now I'm scared. Please, please, don't netkop me.

    >
    > Keith. How can you criticize him for "#" when you use "]" on occasion?


    I use "]" only when I'm quoting something that doesn't come directly
    from the parent article; using ">" in that context could be
    misleading. I've never heard of any newsreader having problems with
    "]" (if you know of one that does, please let me know). Multiple
    people have said that "#" does cause problems. It can be argued that
    that's a bug in those newsreaders, but I see no point in deliberately
    and repeatedly triggering that bug. (In my own newsreader, it's not
    much of a problem, except that the command to re-fill a paragraph
    doesn't recognize a leading "#" as a quoting character; it does
    recognize both ">" and "]".)

    SM Ryan has been asked repeatedly why he insists on using "#"; he has
    never answered. I can only assume he's being deliberately obnoxious,
    which is why I usually ignore him. (I usually try to ignore you as
    well, but this was actually a reasonable question.)

    --
    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, Mar 27, 2006
    #15
  16. Re: passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

    On Mon, 27 Mar 2006 20:33:34 GMT, in comp.lang.c , Keith Thompson
    <> wrote:

    >SM Ryan has been asked repeatedly why he insists on using "#"; he has
    >never answered.


    Actually, I recall that he did. He said at one point that he'd written
    his own newsreader and deliberately designed it to use this character
    for quotes for an unknown reason. When challenged, he got stroppy and
    said everyone else's s/w was broken. Go figure...

    Mark McIntyre
    --
    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Mar 27, 2006
    #16
  17. jimjim

    Jordan Abel Guest

    Re: passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer

    On 2006-03-27, Keith Thompson <> wrote:
    > "Rod Pemberton" <> writes:
    >> "SM Ryan" <> wrote in
    >> message news:...
    >>> # The question was posted by "jimjim" <>.
    >>> # Please don't snip attributions. And *please* stop using your stupid
    >>> # '#' quoting character. You've been told repeatedly that it causes
    >>> # problems for some newsreaders; your stubbornness on this point is why
    >>> # I usually ignore anything you post.
    >>>
    >>> Now I'm scared. Please, please, don't netkop me.

    >>
    >> Keith. How can you criticize him for "#" when you use "]" on occasion?

    >
    > I use "]" only when I'm quoting something that doesn't come directly
    > from the parent article;
    >


    I use | for that purpose, it works better in my newsreader.

    > using ">" in that context could be misleading. I've never heard of
    > any newsreader having problems with "]" (if you know of one that does,
    > please let me know).


    My editor doesn't allow me to easily reflow text with quote markers
    other than > and # by default. However, I have altered the default
    setting, and I may alter it further.

    > Multiple people have said that "#" does cause problems. It can be
    > argued that that's a bug in those newsreaders, but I see no point in
    > deliberately and repeatedly triggering that bug.


    Which newsreaders are those? Mine doesn't color either # or ] properly,
    but I could change that if i cared. oddly, it recognizes = as a quote
    marker.

    > (In my own newsreader, it's not much of a problem, except that the
    > command to re-fill a paragraph doesn't recognize a leading "#" as
    > a quoting character; it does recognize both ">" and "]".)


    > SM Ryan has been asked repeatedly why he insists on using "#"; he has
    > never answered. I can only assume he's being deliberately obnoxious,
    > which is why I usually ignore him. (I usually try to ignore you as
    > well, but this was actually a reasonable question.)


    What _does_ it break? It's hard to imagine what that could break, other
    than people whining that it doesn't format it as a blockquote in their
    gui newsreaders. Do non-quoted lines beginning in # also break them? in
    that case, how does it know the difference? What i'm saying is, does it
    actually _break_ them, or does it somehow fail to be recognized as
    quoted text, and if the latter, is that really worth caring about?

    If the newsreader really breakes, like, crashes, or fails to display, on
    lines beginning in #, that is a serious bug in the newsreader and there
    are much more serious problems than people using it as a quote marker.
    If it just doesn't format it or color it or do other special things
    based on it being quoted text, that's not really worth giving a crap
    about IMO.
    Jordan Abel, Mar 28, 2006
    #17
    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. CRON
    Replies:
    24
    Views:
    200,688
    Adrienne Boswell
    Jun 20, 2006
  2. Johnny
    Replies:
    3
    Views:
    455
    Robert Kern
    Aug 23, 2005
  3. Hari Sekhon
    Replies:
    0
    Views:
    502
    Hari Sekhon
    Jun 20, 2006
  4. Vinko Vrsalovic

    int func() v/s int func(void)

    Vinko Vrsalovic, Jan 21, 2005, in forum: C Programming
    Replies:
    14
    Views:
    1,308
    Villy Kruse
    Jan 24, 2005
  5. Replies:
    5
    Views:
    202
    Ian Macdonald
    Dec 15, 2003
Loading...

Share This Page