Hi, Note that if one uses static void my_print2(const archive_node & n); from the GiNaC Tutorial for expressions that has lenghty string then the result of get_string produces some garbage at the end of string. For example, the following code int main(void) { ex e = pow(200, 500); archive ar(e, "e"); my_print2(ar.get_top_node(0)); cout << endl; return 0; } outputs numeric(number="3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000|õÿ¿_+@xÔõÿ¿") I am using GiNaC 0.9.2, gcc 2.95.2, Linux MD 7.0. Best regards, Pearu
On Thu, 16 Aug 2001, Pearu Peterson wrote:
Note that if one uses static void my_print2(const archive_node & n); from the GiNaC Tutorial for expressions that has lenghty string then the result of get_string produces some garbage at the end of string. For example, the following code
int main(void) { ex e = pow(200, 500); archive ar(e, "e"); my_print2(ar.get_top_node(0)); cout << endl; return 0; }
outputs
numeric(number="32733906078961418700131896968275991522166420460430647894832913680961337964046745548832700923259041571508866841275600710092172565458853930533285275893760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000! 00! 000000000000000000000000000000000000000000000000000|õÿ¿_+@xÔõÿ¿")
I am using GiNaC 0.9.2, gcc 2.95.2, Linux MD 7.0.
Pearu, this is unreproducible: it doesn't produce that garbage here. What version of CLN are you using and what were the exact compiler switches CLN and GiNaC were compiled with? Can other people please try to see if they can reproduce Pearu's problem on their system? Thanks. Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Thu, 16 Aug 2001, Richard B. Kreckel wrote:
Pearu, this is unreproducible: it doesn't produce that garbage here. What version of CLN are you using and what were the exact compiler switches CLN and GiNaC were compiled with?
CLN is 1.1. And the command line is: g++ test_archive.cpp -lcln -lginac
Can other people please try to see if they can reproduce Pearu's problem on their system? Thanks.
I have the same problem on Debian potato. With 'g++ -v' it outputs (if it helps): Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) /usr/lib/gcc-lib/i386-linux/2.95.2/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ test_archive.cpp /tmp/ccTyAyTw.ii GNU CPP version 2.95.2 20000220 (Debian GNU/Linux) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i386-linux/2.95.2/../../../../include/g++-3 /usr/local/include /usr/lib/gcc-lib/i386-linux/2.95.2/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/lib/gcc-lib/i386-linux/2.95.2/../../../../i386-linux/include End of omitted list. /usr/lib/gcc-lib/i386-linux/2.95.2/cc1plus /tmp/ccTyAyTw.ii -quiet -dumpbase test_archive.cc -version -o /tmp/ccxGXIip.s GNU C++ version 2.95.2 20000220 (Debian GNU/Linux) (i386-linux) compiled by GNU C version 2.95.2 20000220 (Debian GNU/Linux). as -V -Qy -o /tmp/cc0FqGDp.o /tmp/ccxGXIip.s GNU assembler version 2.9.5 (i386-linux) using BFD version 2.9.5.0.37 /usr/lib/gcc-lib/i386-linux/2.95.2/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/2.95.2/crtbegin.o -L/usr/lib/gcc-lib/i386-linux/2.95.2 /tmp/cc0FqGDp.o -lcln -lginac -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-linux/2.95.2/crtend.o /usr/lib/crtn.o Pearu
On Thu, 16 Aug 2001, Richard B. Kreckel wrote:
Pearu, this is unreproducible: it doesn't produce that garbage here. What version of CLN are you using and what were the exact compiler switches CLN and GiNaC were compiled with?
CLN is 1.1. And the command line is: g++ test_archive.cpp -lcln -lginac
Can other people please try to see if they can reproduce Pearu's problem on their system? Thanks.
I have the same problem on Debian potato.
With 'g++ -v' it outputs (if it helps):
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) ^^^^^^^^ Still negative. I also tried it on a RedHat 7.1.93 (Roswell) box and Debian's testing distribution (Woody). The string above looks like a vanilla Debian box. We use the very same compiler over here. We use CLN-1.1.2 but AFAICT there were no problems on Intel-arch with older versions. Are you really running CLN-1.1 and not 1.1.1 or 1.1.2? Are you using a Debian package of CLN? If so, which is the precise version? Can you update to CLN-1.1.2 and see if the problem persists? If so, could you
On Thu, 16 Aug 2001, Pearu Peterson wrote: please send us the exact lines how to reproduce it, beginning from configure-flags, the values of CXXFLAGS, CPPFLAGS, LDFLAGS and all this for both CLN and GiNaC? Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
Hi again, On Thu, 16 Aug 2001, Richard B. Kreckel wrote:
Still negative. I also tried it on a RedHat 7.1.93 (Roswell) box and Debian's testing distribution (Woody). The string above looks like a vanilla Debian box. We use the very same compiler over here. We use CLN-1.1.2 but AFAICT there were no problems on Intel-arch with older versions. Are you really running CLN-1.1 and not 1.1.1 or 1.1.2? Are you using a Debian package of CLN? If so, which is the precise version? Can you update to CLN-1.1.2 and see if the problem persists? If so, could you please send us the exact lines how to reproduce it, beginning from configure-flags, the values of CXXFLAGS, CPPFLAGS, LDFLAGS and all this for both CLN and GiNaC?
Now I have updated CLN from a tar-balls and GiNaC from CVS:
cln-config --version --libs --cppflags 1.1.2 -L/opt/cln-1.1.2/lib -lcln -lgmp -I/opt/cln-1.1.2/include
(GMP is 3.1.1)
ginac-config --version --libs --cppflags 0.9.3 -L/opt/GiNaC-0.9.3-17Aug2001/lib -lginac -L/opt/cln-1.1.2/lib -lcln -lgmp -I/opt/GiNaC-0.9.3-17Aug2001/include -I/opt/cln-1.1.2/include
No CXXFLAGS, CPPFLAGS, LDFLAGS were specified during the configurations.
uname -a Linux ath 2.2.18-mosix #1 Tue Jan 9 11:20:28 EET 2001 i686 unknown
Debian 2.2
gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux)
I have reduced the test case to: /* test.cpp */ #include <ginac/ginac.h> using namespace GiNaC; using namespace std; int main(void) { ex e = pow(200, 500); archive ar(e, "e"); const archive_node &n = ar.get_top_node(0); n.printraw(cout); cout << endl; string x; n.find_string("number", x); cout << x << endl; cout << "length=" << x.length() << " (should be 1152)" << endl; return 0; } Compilation: g++ test.cpp -lginac -lcln And the output is (basic * 0x8052fa8 = 32733906078961418700131896968275991522166420460430647894832913680961337964046745548832700923259041571508866841275600710092172565458853930533285275893760000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) string "class" 1 string "number" 3 3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000¼øÿ¿m*@¨ùÿ¿ length=1040 (should be 1152) It seems to me that something gets wrong in C++, not in GiNaC. I have run out of ideas how to fix this garbage --- it is a third Linux system that has this same problem (two Debians, one Mandrake, all have the same gcc version). Any hints are appreciated. Regards, Pearu
Hi, On Fri, 17 Aug 2001, Pearu Peterson wrote:
uname -a Linux ath 2.2.18-mosix #1 Tue Jan 9 11:20:28 EET 2001 i686 unknown ^^^^^ Just a random bubble: are all affected boxen running Mosixized kernels?
It seems to me that something gets wrong in C++, not in GiNaC. I have run out of ideas how to fix this garbage --- it is a third Linux system that has this same problem (two Debians, one Mandrake, all have the same gcc version). Any hints are appreciated.
I am still having no success reproducing this garbage on a variety of boxen, including strange IRIX machines. As to potato, I just recall that our's isn't vanilla. When I was porting to GCC-3.0 I ran into a well-documented problem with binutils on that distribution so I had to manually update them: higgs:~$ ld -v GNU ld version 2.10.91 (with BFD 2.10.1.0.2) Everything else is vanilla, though. Especially g++. However, I don't see how binutils may affect the running behaviour. Mind updating them nevertheless? Do you have any machine where it works or is this a 100% failure? Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Fri, 17 Aug 2001, Richard B. Kreckel wrote:
On Fri, 17 Aug 2001, Pearu Peterson wrote:
uname -a Linux ath 2.2.18-mosix #1 Tue Jan 9 11:20:28 EET 2001 i686 unknown ^^^^^ Just a random bubble: are all affected boxen running Mosixized kernels?
Nope.
It seems to me that something gets wrong in C++, not in GiNaC. I have run out of ideas how to fix this garbage --- it is a third Linux system that has this same problem (two Debians, one Mandrake, all have the same gcc version). Any hints are appreciated.
I am still having no success reproducing this garbage on a variety of boxen, including strange IRIX machines. As to potato, I just recall that our's isn't vanilla. When I was porting to GCC-3.0 I ran into a well-documented problem with binutils on that distribution so I had to manually update them: higgs:~$ ld -v GNU ld version 2.10.91 (with BFD 2.10.1.0.2)
Our Linux boxes have: GNU ld version 2.9.5 (with BFD 2.9.5.0.37) - Debian GNU ld version 2.9.5 (with BFD 2.9.5.0.16) - MD
Everything else is vanilla, though. Especially g++. However, I don't see how binutils may affect the running behaviour. Mind updating them nevertheless? Do you have any machine where it works or is this a 100% failure?
So far the 100%. I haven't tried our Linux Alpha boxes (RedHat 6.1) yet. There I need to install GiNaC first ... Thanks, Pearu
Hi, 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. 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)? Regards, Pearu
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/>
participants (2)
-
Pearu Peterson
-
Richard B. Kreckel