isnan stopped working - Boost-users - lists.preview.boost.org

newer
Possible bug in...

isnan stopped working

older
proto: BOOST_PROTO_AUTO

Thijs Koerselman

4 Jan 2009 4 Jan '09

10:11 p.m.

isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work? float nan = FP_NAN; int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); isnan never returns anything. The value of ret is still 0xdeadbeef after invoking isnan() I'm on OSX10.5.6 using XCode 3 if that helps. Thijs

Attachments:

attachment.html (text/html — 432 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

John Maddock

5 Jan 5 Jan

9:56 a.m.

isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work?

float nan = FP_NAN; int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);

isnan never returns anything. The value of ret is still 0xdeadbeef after invoking isnan()

I'm on OSX10.5.6 using XCode 3 if that helps.

No idea: the tests all seem to be passing on that platform. Are you able to step into the code for isnan to see what's happening? It has to return *something* IMO... John.

Reply

Sign in to reply online Use email software

Bernhard Walle

10:05 a.m.

* Thijs Koerselman [2009-01-04 23:11]:

isnan() and family seems to have stopped working in my code. The only thing I can remember is updating from 1.36 to 1.37. Any idea why the following wouldn't work?

float nan = FP_NAN;

That's just 3. Use std::numeric_limits<float>::quiet_NaN() from <limits>. See the example below that works for me on Linux with Boost 1.36 and g++ 4.3.2.

int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);

isnan never returns anything.

Well, in my tests on Linux that is set to 0 in your example. Regards, Bernhard #include <iostream> #include <limits> #include int main(int argc, char *argv[]) { float nan = std::numeric_limits<float>::quiet_NaN(); int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); std::cout << ret << std::endl; return 0; }

Reply

Sign in to reply online Use email software

Thijs Koerselman

8:23 p.m.

On Mon, Jan 5, 2009 at 11:05 AM, Bernhard Walle wrote:

...
float nan = FP_NAN;

That's just 3.

Use std::numeric_limits<float>::quiet_NaN() from <limits>. See the example below that works for me on Linux with Boost 1.36 and g++ 4.3.2.

Aha! thanks. I was wondering why it was an enum :) (it's 1 on my platform).

...
int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan);

isnan never returns anything.

Well, in my tests on Linux that is set to 0 in your example.

Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that. So the enum was the original reason for my code not working. The only thing I'm still wondering about is why it did work before, when I was using the enum with the earlier version. It's a completely different value for NaN. It doesn't matter anymore, now everything is sorted. Thanks everyone for helping out. Cheers, Thijs

Reply

Sign in to reply online Use email software

Bernhard Walle

6 Jan 6 Jan

8:46 a.m.

* Thijs Koerselman [2009-01-05 21:23]:

Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.

That could be an optimisation. Do you compile with -O0 (or without any -O)? Regards, Bernhard

Reply

Sign in to reply online Use email software

Thijs Koerselman

4:38 p.m.

On Tue, Jan 6, 2009 at 9:46 AM, Bernhard Walle wrote:

...
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.

That could be an optimisation. Do you compile with -O0 (or without any -O)?

I accidentally had it set to -Os, but changing it back to -O0 doesn't seem to make a difference in this case. You may be right about the optimization though, because if I put an extra dummy statement in like "ret = ret" it is also skipped by gdb. Thijs

Reply

Sign in to reply online Use email software

Bernhard Walle

4:47 p.m.

* Thijs Koerselman [2009-01-06 17:38]:

On Tue, Jan 6, 2009 at 9:46 AM, Bernhard Walle wrote:

...
...
Sorry it DOES work. When i step over the last assignment to the end of the function block, XCode doesn't update the value of ret in the debugging window. It still displays 0xdeadbeaf, even though the value has changed. So it did return a value. I wonder if this is intended. I can't think of a good reason why XCode it would work like that.

That could be an optimisation. Do you compile with -O0 (or without any -O)?

I accidentally had it set to -Os, but changing it back to -O0 doesn't seem to make a difference in this case. You may be right about the optimization though, because if I put an extra dummy statement in like "ret = ret" it is also skipped by gdb.

Works here: kopernikus % cat boost.cc #include <iostream> #include <limits> #include int main(int argc, char *argv[]) { float nan = std::numeric_limits<float>::quiet_NaN(); int ret = 0xdeadbeef; ret = (boost::math::isnan)(nan); return 0; } kopernikus % g++ -g -o boost boost.cc kopernikus % gdb ./boost GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) break 11 Breakpoint 1 at 0x8048651: file boost.cc, line 11. (gdb) r Starting program: /home/bwalle/boost Breakpoint 1, main () at boost.cc:11 11 return 0; (gdb) p ret $1 = 1 (gdb) quit The program is running. Exit anyway? (y or n) y Regards, Bernhard

Reply

Sign in to reply online Use email software

5892

Age (days ago)

5894

Last active (days ago)

Download

6 comments

3 participants

tags

participants (3)

Bernhard Walle
John Maddock
Thijs Koerselman