This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/3720: Problems with num_get
- From: Philip Martin <philip at codematters dot co dot uk>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: bkoz at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, schmid at snake dot iap dot physik dot tu-darmstadt dot de
- Date: 08 Dec 2001 01:25:45 +0000
- Subject: Re: libstdc++/3720: Problems with num_get
- Envelope-to: gcc-prs@gcc.gnu.org
- References: <Pine.LNX.4.10.10112071616450.12791-100000@fencer.cygnus.com>
Benjamin Kosnik <bkoz@redhat.com> writes:
> > 3. Trying the code, input of std::numeric_limits<T>::max() in octal or
> > hex doesn't appear to work for integers, e.g. reading 017777777777
> > into a long on x86 doesn't work, it appears to accept one character
> > too few. Decimal works.
>
> Hmm. I'll look at this, thanks.
I was assuming that
std::istringstream i( "017777777777" );
long x = 0;
i >> x;
would deduce octal from the leading zero, as that's what stdio "%i"
does. Investigation shows that it is reading decimal, which is then
one digit too long. Using an explicit manipulator
i >> std::setbase(0) >> x;
or
i >> std::oct >> x;
causes the number to be read correctly. I suppose it's table 89 in
27.4.4.1 that determines that dec is the default? I didn't expect
that.
Philip