cin >> hex >> i behaves unexpectedly

cin >> hex >> i behaves unexpectedly

[Martin Dickopp]

Hi,

If I compile the following program


#include <iostream>
int main ()
{
  int i;
  cin >> hex >> i;
  cout << i << endl;
  return 0;
}


either with egcs-1.1.2 or with the June 29 snapshot, and then run it
and provide 0xff as input, 0 is assigned to i.  However, if I provide ff
as input, 255 is assigned to i.  In other words, the 0x prefix is not
recoginzed in hex mode.  The patch below fixes this problem.

Regards,
Martin



diff -u --recursive egcs.orig/libio/iostream.cc egcs/libio/iostream.cc
--- egcs.orig/libio/iostream.cc	Wed Jun 30 22:58:19 1999
+++ egcs/libio/iostream.cc	Wed Jun 30 22:31:31 1999
@@ -268,8 +268,20 @@
 	    }
 	}
     }
-    else if ((stream.flags() & ios::basefield) == ios::hex)
+    else if ((stream.flags() & ios::basefield) == ios::hex) {
 	base = 16;
+	if (ch == '0') {
+	    ch = sb->sbumpc();
+	    if (ch == EOF) {
+		val = 0;
+		return 1;
+	    }
+	    if (ch == 'x' || ch == 'X') {
+		ch = sb->sbumpc();
+		if (ch == EOF) goto eof_fail;
+	    }
+	}
+    }
     else if ((stream.flags() & ios::basefield) == ios::oct)
 	base = 8;
     val = 0;



-- 
Martin Dickopp                Email: dickopp@pktw06.phy.tu-dresden.de
Inst. f. Kern- und Teilchenphysik, TU Dresden, 01062 Dresden, Germany
Office ASB E22       Phone +49-351-463-3107      Fax +49-351-463-3114

Re: cin >> hex >> i behaves unexpectedly

[Alexandre Oliva]

On Jun 30, 1999, Martin Dickopp <martin@pktw16.phy.tu-dresden.de> wrote:

>   cin >> hex >> i;

> provide 0xff as input, 0 is assigned to i.

Can anyone point to a passage in the Standard in which it says that
`0x' should be discarded when expecting an hex number?  I couldn't
find it anywhere, but I didn't look for it very thorougly.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: cin >> hex >> i behaves unexpectedly

[Martin Dickopp]

On 1 Jul 1999, Alexandre Oliva wrote:

> On Jun 30, 1999, Martin Dickopp <martin@pktw16.phy.tu-dresden.de> wrote:
> 
> >   cin >> hex >> i;
> 
> > provide 0xff as input, 0 is assigned to i.
> 
> Can anyone point to a passage in the Standard in which it says that
> `0x' should be discarded when expecting an hex number?  I couldn't
> find it anywhere, but I didn't look for it very thorougly.

Hi,

I only have the 1997 Draft here, not the Standard itself, so someone
should verify if the following is still true in the Standard.

The Draft says in section 27.6.1.2.2 ("Arithmetic Extractors")
that `basic_istream<charT,traits>& operator>>(int&)' should behave
like the following code fragment:

  typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
  iostate err = 0;
  use_facet< numget >(loc).get(*this, 0, *this, err, val);
  setstate(err);

According to section 22.2.2.1.2 ("num_get virtual functions"),
`num_get' parses the input like `scanf ("%x", ...)' if `basefield == hex
&& !uppercase' or like `scanf ("%X", ...)' if `basefield == hex'
(so my suggested patch is incorrect in that it ignores `uppercase').

Section 27.8.2 ("C Library files") refers to the C Standard for
the behaviour of `scanf'.  Unfortunately, I don't have a C Standard
either, but publicly available sources
(e.g. ` http://www.dinkumware.com/htm_cl/ ') indicate that `scanf
("%x", ...)' should parse like `strtoul (str, endptr, 16)', which
(according to ` http://www.dinkumware.com/htm_cl/stdlib.html#strtol ')
"... accepts the sequences 0x or 0X only when base equals zero or 16."

Martin


-- 
Martin Dickopp                Email: dickopp@pktw06.phy.tu-dresden.de
Inst. f. Kern- und Teilchenphysik, TU Dresden, 01062 Dresden, Germany
Office ASB E22       Phone +49-351-463-3107      Fax +49-351-463-3114