Bug in boost::format with 0 valued integer
Hi folks,
There appears to be a bug in boost::format, an unitialized value
problem spotted when I was using valgrind on a program of mine.
The following test code illustrates the (admittedly minor?) problem:
#include
Hi folks,
There appears to be a bug in boost::format, an unitialized value problem spotted when I was using valgrind on a program of mine.
The following test code illustrates the (admittedly minor?) problem:
Hi, sorry for the late reply, I dont check boost.user too often, and then it took for me to get it to accept my messages. I dont know valgrind, and I'm not sure I can figure out the nice logs you sent. it looks like a powerful tool, but does it say which variable is used uninitialised ? (and what compiler are you using format with, and does the sample code do anything weird there ?) I greatly doubt it is in format's code, I can find no possible reason for different behaviour between the 2 calls, within format's code. While in fact the stdlib's ostream code could very well do some tests and get in trouble with 0-valued int. Could it likely come from some code in the standard lib ? Also, I notice some lines in the valgrind report are left unmangled, could the analysis get mixed up at run-time for whatever reason, and detect an unitialised value by mistake ? regards, -- Samuel (boost::format author)
==28879== Conditional jump or move depends on uninitialised value(s) ==28879== at 0x40289470: (within /usr/lib/libstdc++.so.5.0.3) ... ==28879== by 0x4028F36B: std::ostream::operator<<(int) (in
I don't know much about valgrind, but doesn't this mean the problem is in stdlib functions called by format, and not format itself ?? I've downloaded and tried valgrind. Now I understand : valgrind reports the stacktrace at the moment of detection, but doesnt know where in the stack the variable was created. It sees the uninitialised read, not the function responsible for creating the variable and passing it unitialised. Right ? Well anyhow, I too get these reports for the following code (that's roughly what the format code does to its internal stream for %05d ) : #include <iostream> #include <iomanip> int main() { using namespace std; int dummy = 0; cout << setw(5) << setfill('0') << internal << dummy << endl; } So it definitely has nothing to do with format. [ Whaaat ?! A bug ? in _my_ code ? Surely you must be joking, mister. :-)] more seriously, I don't think the libstdc++ is doing something wrong either. from a quick glance at the doc : On rare occasions, optimisation levels at -O2 and above have been observed to generate code which fools memcheck into wrongly reporting uninitialised value errors. And the libstdc++ is the kind of code that is compiled with as much optimisation as possible. I guess there's no need to look any further. Maybe report the case to valgrind, in case they like to know about those "rare occasions". If that can be useful to you, I tried intel-linux-7.1 on that, and valgrind doesnt report anything there. Regards, -- Samuel
participants (2)
-
Samuel Krempp -
Simon Clift