bug(?): garbage produced by archive_node.get_string

[Pearu Peterson]

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