cin>> wont work (tried redhat & debian)

[Samuel dot Krempp at crans dot ens-cachan dot fr]

Whatever I try, cin>>x wont work, x be a string, float or whatever.
even cin.get(c). ifstreams work perfect.
In fact, after I try to take any input from cin, its state is EOF (plus failbit
if using .get(c), but only eof with cin>>x ), as can be
seen from this example code + output.

Code :
#include <iostream>
#include <fstream>
#include <unistd.h>
#include <string>

using namespace std;

int main() {
	int n=666;
	float x=666.666;
	cout<<"rdstate before anything : "
	    <<cin.rdstate()<<endl;
	cerr<<"good eof fail bad "
	    << ios::goodbit<<" "
	    <<ios::eofbit<<" "
	    <<ios::failbit<<" "
	    <<ios::badbit<<endl;

	cout<<"rdstate to make sure : "
	    <<cin.rdstate()<<endl;
	cout<<" enter n : ";
	cin>>n;
	cout<<"rdstate after cin>>n : "
	    <<cin.rdstate()<<endl;
	cout<<" enter x : ";
	cin>>x;
	cerr<<"n :"<<n<<" x:"<<x<<endl;
	ifstream f("toto.txt");
	f>>n;
	cerr<<" fsteam's n: "<<n<<endl;
}	


Output:

rdstate before anything : 0
good eof fail bad 0 16 32 16384
rdstate to make sure : 0
 enter n : 99
rdstate after cin>>n : 16
n :666 x:666.666
 fsteam's n: 345

(toto.txt contains "345\n" )
Of course, this bad cin is fixed when compiling gcc without enable-libstdcxx-v3.

This behaviour is the same on the 2 Systems I tried. (Redhat6.2 and Debian
Woody)

Here are the details :
-------------------
System 1 = RedHat 6.2, libc-2.1.3.so
/usr/include/linux is unfortunately pointing inside the kernel sources, but as
it is a 2.2.14 I think that should be ok. (and anyway I'm not root there)

hermes:% echo $LD_LIBRARY_PATH
/home/krempp/egcsv3/lib:/home/krempp/lib
hermes:% echo $LD_RUN_PATH 
/home/krempp/egcsv3/lib:/home/krempp/lib

hermes:% ~/egcsv3/bin/g++ -v
Reading specs from /home/krempp/egcsv3/lib/gcc-lib/i686-pc-linux-gnu/2.97/specs
Configured with:  --prefix=/home/krempp/egcsv3 --enable-shared --with-gnu-ld
--with-gnu-as --enable-libstdcxx-v3
gcc version 2.97 20001021 (experimental)

-------------------
System 2 = Debian Woody updated with latest packages, and strange new glibc
libc-2.1.95.so
/usr/include/linux are the headers delivered by debian in libc-dev package.
Same g++.
Same symptoms.
-------------------

I built the CVS sources, in another ("Begcs") directory and configuring with
"../CVSgcc.configure (....)", then make, make install
I tried make bootstrap wihtout any difference in the symptoms.

So, what did I do wrong ? or then how come I'm the first to have this problem ?

otherwise, I'm very happy to see the full standard library implemented in 
gcc and about to be easily available. I waited for this for a years.. Thanks !

-- 
Sam
PS: btw, is there any documentation about the extension TREE class ? I cant find
this one on the SGI site..