446,171 Members | 1,027 Online Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

# NAN error and debugging with GDB

 P: n/a 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 Nov 14 '05 #1
10 Replies

 P: n/a 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. Nov 14 '05 #2

 P: n/a 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 #include 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 : #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case 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. -- Er*********@sun.com Nov 14 '05 #3

 P: n/a 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 #include 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 : #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case 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? ;-) Nov 14 '05 #4

 P: n/a Eric Sosman wrote in message news:<3F***************@sun.com>... #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case defines it as a macro */ #define sqrt(x) my_sqrt((x), __FILE__, __LINE__) ^^^ Why parenthesise x here? -- Peter Nov 14 '05 #5

 P: n/a ai***@acay.com.au (Peter Nilsson) writes: Eric Sosman wrote in message news:<3F***************@sun.com>... #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case 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) ks***@mib.org San Diego Supercomputer Center <*> Schroedinger does Shakespeare: "To be *and* not to be" Nov 14 '05 #6

 P: n/a Keith Thompson wrote: ai***@acay.com.au (Peter Nilsson) writes: Eric Sosman wrote in message #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case 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 (cb********@yahoo.com) (cb********@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! Nov 14 '05 #7

 P: n/a 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. Nov 14 '05 #8

 P: n/a CBFalconer writes: Keith Thompson wrote: ai***@acay.com.au (Peter Nilsson) writes: Eric Sosman wrote in message > > #include > ... > double my_sqrt(double, const char*, int); > #undef sqrt /* in case 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) ks***@mib.org San Diego Supercomputer Center <*> Schroedinger does Shakespeare: "To be *and* not to be" Nov 14 '05 #9

 P: n/a Peter Nilsson wrote: Eric Sosman wrote in message news:<3F***************@sun.com>... #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case defines it as a macro */ #define sqrt(x) my_sqrt((x), __FILE__, __LINE__) ^^^ Why parenthesise x here? Because (good habits) are (hard (to break))? -- Er*********@sun.com Nov 14 '05 #10

 P: n/a Keith Thompson wrote in message news:... ai***@acay.com.au (Peter Nilsson) writes: Eric Sosman wrote in message news:<3F***************@sun.com>... #include ... double my_sqrt(double, const char*, int); #undef sqrt /* in case defines it as a macro */ #define sqrt(x) my_sqrt((x), __FILE__, __LINE__) ^^^ Why parenthesise x here? ... 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 Nov 14 '05 #11

### This discussion thread is closed

Replies have been disabled for this discussion. 