|
From: Nicholas N. <nj...@cs...> - 2007-08-07 22:07:23
|
On Tue, 7 Aug 2007, Evan Lavelle wrote: > I have a problem with some C++ code when using a long double type. A > long double is reported as 16 bytes on this system, but Valgrind reports > an error if I set a char pointer to the start of the long double, and > then try to read 16 bytes from it. > > The problem seems to be straightforward, and is that Valgrind is smart > enough to know that a long double is actually 10 bytes, rather than 16 > bytes, and it's reporting the top bytes as uninitialised (see > http://osdir.com/ml/debugging.valgrind/2005-08/msg00376.html). > > Question: is there a smart way to get rid of these error messages? I > have a lot of templated code that deals with arbitrary floating-point > types, and it relies on 'sizeof' to tell it how big the type is. > 'sizeof' tells me that a long double is 16 bytes, so I copy around and > manipulate 16-byte quantities. I can get rid of the error messages by > assuming that long doubles are actually 80 bits, and not 128 bits, but > I'd rather not hard-wire this assumption into the code. > > Initialising an area of memory and then copying the long doubles into it > doesn't work: Valgrind still reports an error, because the copy in of > the long double still sets the top 6 bytes to uninitialised data. > > Any ideas? How does Valgrind know that a long double is 80 bits anyway? Valgrind works entirely at the binary level, and it knows that x86 FP registers are 80 bits. The errors at that website are all like this: =15339== Syscall param write(buf) points to uninitialised byte(s) ==15339== at 0x503B03: __write_nocancel (in /lib/libc-2.3.5.so) ==15339== by 0x4A6378: new_do_write (in /lib/libc-2.3.5.so) ==15339== by 0x4A6474: _IO_do_write@@GLIBC_2.1 (in /lib/libc-2.3.5.so) ==15339== by 0x4A5C6A: _IO_file_close_it@@GLIBC_2.1 (in /lib/libc-2.3.5.so) ==15339== by 0x49CC55: fclose@@GLIBC_2.1 (in /lib/libc-2.3.5.so) ==15339== by 0x804C952: test_complex_long_double_file (test_complex_source.c:433) ==15339== by 0x8063828: main (test.c:205) So it seems you're passing these partially undefined 16 byte values to the write() system call. That lookss like a genuine bug. Just copying around undefined data won't cause Valgrind to complain, it only complains when you use undefined data in ways that may affect execution, and passing the data to a system call like write() is one such case. Nick |