Hi, On Sat, 18 Aug 2001, Pearu Peterson wrote:
I finally tracked down what caused this garbage. It was due to void numeric::archive(archive_node &n) const in numeric.cpp where a fixed size buffer is defined if HAVE_SSTREAM is undefined.
Doh! I was completely forgetting that our gcc-2.95.2 is vanilla with the exception that I have dropped the attached file into /usr/include/g++-3/. I recommend that you do the same. GCC-2.95.3 has this hack, too. And GCC-3.0 has a cleaner implementation of course. Applying self-LART...
If I made the following changes
$ diff numeric.cpp numeric.cpp.orig 307c307,308 < std::ostrstream s; ---
char buf[1024]; std::ostrstream s(buf, 1024);
329c330,332 < n.add_string("number", s.str()); ---
s << ends; std::string str(buf); n.add_string("number", str);
then the garbage disappered.
So, why you define fixed size buffer if ostrstream has the same functionality as ostringstream (at least in gcc system)?
I didn't know this works. We were under the impression that fixed-size buffers are a must for ostrstream. This misunderstanding was probably due to exercise 26 in chapter 21 of Stroustrup's TC++PL3 where only the ctor we use is mentioned. Looking at the standard's Annex D one finds the ctor you use indeed documented, so this fix would probably be sane. I won't fix it though, since ostrstream is officially deprecated anyhow and may eventually be thrown out of GiNaC entirely in favor of ostringstream. If you go through the sources and grep for the dozen or so occurences, fix them and send us a patch, they could still be applied (for a transistion period). Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>