Q: (d = NAN) != NAN?
Hello!
Probably I'm doing something wrong, but I have some problems comparing a double
with NAN: The value is NAN, but the test fails. Probably I should use isnana().
Here's my test case:
---
#include
#include
int main()
{
double d = NAN;
assert(d == NAN);
return 0;
}
---
The output is:
---
> ./foo
foo: foo.c:8: main: Assertion `d == (__builtin_nanf (""))' failed.
Aborted
---
Code is:
---
Dump of assembler code for function main:
0x0040059a <+0>: push %rbp
0x0040059b <+1>: mov%rsp,%rbp
0x0040059e <+4>: sub$0x10,%rsp
0x004005a2 <+8>: mov%fs:0x28,%rax
0x004005ab <+17>:mov%rax,-0x8(%rbp)
0x004005af <+21>:xor%eax,%eax
0x004005b1 <+23>:movabs $0x7ff8,%rax
0x004005bb <+33>:mov%rax,-0x10(%rbp)
0x004005bf <+37>:mov$0x4006d4,%ecx
0x004005c4 <+42>:mov$0x8,%edx
0x004005c9 <+47>:mov$0x4006d9,%esi
0x004005ce <+52>:mov$0x4006df,%edi
0x004005d3 <+57>:callq 0x400490 <__assert_fail@plt>
End of assembler dump.
Breakpoint 1, main () at foo.c:8
8 assert(d == NAN);
(gdb) p d
$1 = nan(0x8)
---
Interestingly this always fails: "assert(NAN == NAN);".
Is this a bug in the compiler or the implementation? If not, can there be a
warning about such? I'm using an old "gcc-4_3-branch revision 152973".
Regards,
Ulrich
Obscure iostream failure, a compiler bug or a language design issue?
Hello!
I had a C++ program that crashed, so I added debug output using clog.
Unfortunately the first out put to clog also crashed within iostreams.
I was able to make a test case that compiles fine with -Wall -Wextra, but
crashes:
---ugly code follows---
class d {
public:
static void f();
d() { f(); }
};
d dd;
#include
using namespace std;
void d::f() { clog << "jdfdf" << endl; }
int main(int argc, char *argv[])
{
d::f();
}
---
If you #include before the decalration of "dd", the program works;
if compiled as displayed, it crashes:
---
Program received signal SIGSEGV, Segmentation fault.
0x77b6f501 in std::ostream::sentry::sentry(std::ostream&) ()
from /usr/lib64/libstdc++.so.6
(gdb) bt
#0 0x77b6f501 in std::ostream::sentry::sentry(std::ostream&) ()
from /usr/lib64/libstdc++.so.6
#1 0x77b6fc19 in std::basic_ostream >&
std::__ostream_insert >(std::basic_ostream >&, char const*, long) () from /usr/lib64/libstdc++.so.6
#2 0x77b7001f in std::basic_ostream >&
std::operator<< >(std::basic_ostream >&, char const*) () from /usr/lib64/libstdc++.so.6
#3 0x00400942 in d::f () at t.cc:11
#4 0x00400a6a in d::d (this=0x6011a0 ) at t.cc:4
#5 0x004009d9 in __static_initialization_and_destruction_0 (
__initialize_p=1, __priority=65535) at t.cc:7
#6 0x00400a33 in global constructors keyed to dd() () at t.cc:15
#7 0x00400b46 in __do_global_ctors_aux ()
#8 0x00400783 in _init ()
#9 0x772dcad8 in ?? () from /lib64/libc.so.6
#10 0x00400ad5 in __libc_csu_init (argc=-7936,
argv=0x601080 <_ZSt4clog@@GLIBCXX_3.4>, envp=0x0) at elf-init.c:120
#11 0x772ebbc2 in __libc_start_main () from /lib64/libc.so.6
#12 0x00400859 in _start () at ../sysdeps/x86_64/elf/start.S:113
---
gcc is "gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux" of
SLES11 SP3 (x86_64), but newer compilers react the same.
I guess the problem is that constructors are called sequentially without
dependency analysis. So if d() is acaaled before including iostream
(lexically), the program crashes.
Reagrds,
Ulrich Windl
P.S. Usually I don't write such ugly code
