NAN error and debugging with GDB

Discussion in 'C Programming' started by Codas obfuscatus, Jan 6, 2004.

  1. If I pass a negative number as argument to sqrt() it returns a NAN as
    expected. Is there any way to debug this problem using GDB
    Let me know
    Co
    Codas obfuscatus, Jan 6, 2004
    #1
    1. Advertising

  2. Codas obfuscatus wrote:

    > If I pass a negative number as argument to sqrt() it returns a NAN as
    > expected. Is there any way to debug this problem using GDB
    > Let me know
    > Co


    If it's doing what you expected, I don't see a problem (but note that
    the result of such a domain error is implementation-defined, and not
    necessarily portable).

    Specific tools (such as gdb) are off-topic here. This group discusses
    the C language, not tools.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Jan 6, 2004
    #2
    1. Advertising

  3. Codas obfuscatus

    Eric Sosman Guest

    Codas obfuscatus wrote:
    >
    > If I pass a negative number as argument to sqrt() it returns a NAN as
    > expected. Is there any way to debug this problem using GDB
    > Let me know


    If you are trying to discover what function passes
    the negative argument to sqrt(), one C-only approach
    would be to "wrap" the sqrt() call with your own function:

    #include <stdio.h>
    #include <math.h>
    double my_sqrt(double x, const char *file, int line) {
    if (x < 0.0)
    fprintf (stderr, "sqrt(%g) called from %s, line %d\n",
    x, file, line);
    return sqrt(x);
    }

    Then in each file that calls sqrt(), you would insert
    something like this *after* the #include <math.h>:

    #include <math.h>
    ...
    double my_sqrt(double, const char*, int);
    #undef sqrt /* in case <math.h> defines it as a macro */
    #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    These "intercepting" lines could, of course, reside in
    your own "my_sqrt.h" header file if that's convenient.

    --
    Eric Sosman, Jan 7, 2004
    #3
  4. Eric Sosman wrote:

    > Codas obfuscatus wrote:
    >
    >> If I pass a negative number as argument to sqrt(),
    >> it returns a NAN as expected.
    >> Is there any way to debug this problem using GDB? Let me know.

    >
    >
    > If you are trying to discover what function passes
    > the negative argument to sqrt(), one C-only approach
    > would be to "wrap" the sqrt() call with your own function:
    >
    > #include <stdio.h>
    > #include <math.h>
    > double my_sqrt(double x, const char *file, int line) {
    > if (x < 0.0)
    > fprintf (stderr, "sqrt(%g) called from %s, line %d\n",
    > x, file, line);
    > return sqrt(x);
    > }
    >
    > Then in each file that calls sqrt(), you would insert
    > something like this *after* the #include <math.h>:
    >
    > #include <math.h>
    > ...
    > double my_sqrt(double, const char*, int);
    > #undef sqrt /* in case <math.h> defines it as a macro */
    > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)
    >
    > These "intercepting" lines could, of course, reside in
    > your own "my_sqrt.h" header file if that's convenient.


    That's a *great* idea!
    Where did you get it? ;-)
    E. Robert Tisdale, Jan 7, 2004
    #4
  5. Eric Sosman <> wrote in message news:<>...

    <snip>
    >
    > #include <math.h>
    > ...
    > double my_sqrt(double, const char*, int);
    > #undef sqrt /* in case <math.h> defines it as a macro */
    > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    ^^^
    Why parenthesise x here?

    --
    Peter
    Peter Nilsson, Jan 8, 2004
    #5
  6. (Peter Nilsson) writes:
    > Eric Sosman <> wrote in message
    > news:<>...
    >
    > <snip>
    > >
    > > #include <math.h>
    > > ...
    > > double my_sqrt(double, const char*, int);
    > > #undef sqrt /* in case <math.h> defines it as a macro */
    > > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    > ^^^
    > Why parenthesise x here?


    Because all macro arguments should be fully parenthesized to avoid
    operator precedence problems. (This assumes that the macro is
    supposed to act like a function call and the arguments are supposed to
    be expressions.)

    In this particular case, the argument to the sqrt() macro is already
    enclosed in parentheses, so there may not be any actual argument that
    would be legal for a call to the sqrt() function that would cause
    problems for the sqrt() macro. I've tried and failed to come up with
    a problematic example using the comma operator. But it's much easier
    to add the parentheses than to prove that they're unnecessary in this
    particular case.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Jan 8, 2004
    #6
  7. Codas obfuscatus

    CBFalconer Guest

    Keith Thompson wrote:
    > (Peter Nilsson) writes:
    > > Eric Sosman <> wrote in message
    > >
    > > <snip>
    > > >
    > > > #include <math.h>
    > > > ...
    > > > double my_sqrt(double, const char*, int);
    > > > #undef sqrt /* in case <math.h> defines it as a macro */
    > > > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    > > ^^^
    > > Why parenthesise x here?

    >
    > Because all macro arguments should be fully parenthesized to
    > avoid operator precedence problems. (This assumes that the macro
    > is supposed to act like a function call and the arguments are
    > supposed to be expressions.)
    >
    > In this particular case, the argument to the sqrt() macro is already
    > enclosed in parentheses, so there may not be any actual argument that
    > would be legal for a call to the sqrt() function that would cause
    > problems for the sqrt() macro. I've tried and failed to come up with
    > a problematic example using the comma operator. But it's much easier
    > to add the parentheses than to prove that they're unnecessary in this
    > particular case.


    Won't "foo = sqrt(2, 4);" foul up without the parens? It should
    barf at compile time.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jan 8, 2004
    #7
  8. CBFalconer wrote:

    >>>> #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)
    >>>
    >>> ^^^
    >>>Why parenthesise x here?

    >
    > Won't "foo = sqrt(2, 4);" foul up without the parens? It should
    > barf at compile time.
    >


    Won't it foul up either way? The comma in that context should act as an
    argument separator, not the comma operator, shouldn't it?

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Jan 8, 2004
    #8
  9. CBFalconer <> writes:
    > Keith Thompson wrote:
    > > (Peter Nilsson) writes:
    > > > Eric Sosman <> wrote in message
    > > >
    > > > <snip>
    > > > >
    > > > > #include <math.h>
    > > > > ...
    > > > > double my_sqrt(double, const char*, int);
    > > > > #undef sqrt /* in case <math.h> defines it as a macro */
    > > > > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)
    > > > ^^^
    > > > Why parenthesise x here?

    > >
    > > Because all macro arguments should be fully parenthesized to
    > > avoid operator precedence problems. (This assumes that the macro
    > > is supposed to act like a function call and the arguments are
    > > supposed to be expressions.)
    > >
    > > In this particular case, the argument to the sqrt() macro is already
    > > enclosed in parentheses, so there may not be any actual argument that
    > > would be legal for a call to the sqrt() function that would cause
    > > problems for the sqrt() macro. I've tried and failed to come up with
    > > a problematic example using the comma operator. But it's much easier
    > > to add the parentheses than to prove that they're unnecessary in this
    > > particular case.

    >
    > Won't "foo = sqrt(2, 4);" foul up without the parens? It should
    > barf at compile time.


    That's basically the example I was trying to come up with, but
    "foo = sqrt(2, 4);" would foul up whether sqrt() is a macro or a
    function taking one argument. The resulting error message might be
    confusing, though.

    If you want to pass an expression with a comma operator as a function
    argument, you have to parenthesize it: "foo = sqrt((2, 4));" -- which
    also avoids the problem.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Jan 8, 2004
    #9
  10. Codas obfuscatus

    Eric Sosman Guest

    Peter Nilsson wrote:
    >
    > Eric Sosman <> wrote in message news:<>...
    >
    > <snip>
    > >
    > > #include <math.h>
    > > ...
    > > double my_sqrt(double, const char*, int);
    > > #undef sqrt /* in case <math.h> defines it as a macro */
    > > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    > ^^^
    > Why parenthesise x here?


    Because (good habits) are (hard (to break))?

    --
    Eric Sosman, Jan 8, 2004
    #10
  11. Keith Thompson <> wrote in message news:<>...
    > (Peter Nilsson) writes:
    > > Eric Sosman <> wrote in message
    > > news:<>...
    > >
    > > <snip>
    > > >
    > > > #include <math.h>
    > > > ...
    > > > double my_sqrt(double, const char*, int);
    > > > #undef sqrt /* in case <math.h> defines it as a macro */
    > > > #define sqrt(x) my_sqrt((x), __FILE__, __LINE__)

    > > ^^^
    > > Why parenthesise x here?

    >
    > <snip> ... it's much easier to add the parentheses than to prove that they're
    > unnecessary in this particular case.


    In this particular case, I think it's much easier to leave them out:

    #define sqrt(x) my_sqrt(x, __FILE__, __LINE__)

    As Dan Pop once said, "[it] isn't unclear *at all* and only an expert
    could actually have doubts about it". ;)

    --
    Peter
    Peter Nilsson, Jan 8, 2004
    #11
    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. Surendra
    Replies:
    0
    Views:
    509
    Surendra
    Mar 23, 2006
  2. max(NaN,0) should be NaN

    , Aug 28, 2006, in forum: C Programming
    Replies:
    61
    Views:
    1,255
    Michel Hack
    Sep 8, 2006
  3. seba
    Replies:
    1
    Views:
    1,446
    mlimber
    Mar 22, 2007
  4. Replies:
    6
    Views:
    1,519
    Richard Tobin
    Mar 19, 2009
  5. Timothy Madden
    Replies:
    1
    Views:
    1,631
    Timothy Madden
    Sep 17, 2009
Loading...

Share This Page