NAN error and debugging with GDB

[Codas obfuscatus]

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

[Kevin Goodsell]

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.

[Eric Sosman]

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 "intercepti ng" lines could, of course, reside in
your own "my_sqrt.h" header file if that's convenient.

--
Er*********@sun .com

[E. Robert Tisdale]

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 "intercepti ng" 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? ;-)

[Peter Nilsson]

Eric Sosman <Er*********@su n.com> wrote in message news:<3F******* ********@sun.co m>...

<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

[Keith Thompson]

ai***@acay.com. au (Peter Nilsson) writes:

Eric Sosman <Er*********@su n.com> wrote in message
news:<3F******* ********@sun.co m>...

<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_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[CBFalconer]

Keith Thompson wrote:

ai***@acay.com. au (Peter Nilsson) writes:

Eric Sosman <Er*********@su n.com> 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 (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Kevin Goodsell]

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.

[Keith Thompson]

CBFalconer <cb********@yah oo.com> writes:

Keith Thompson wrote:

ai***@acay.com. au (Peter Nilsson) writes:

Eric Sosman <Er*********@su n.com> 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_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Eric Sosman]

Peter Nilsson wrote:

Eric Sosman <Er*********@su n.com> wrote in message news:<3F******* ********@sun.co m>...

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

--
Er*********@sun .com