[Boost-users] Re: Bug in boost::format with 0 valued integer

From: Samuel Krempp (krempp_at_[hidden])
Date: 2003-09-15 16:44:29

> ==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