Very serious bug...

[Gabriel Dos Reis]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

[...]

| It looks like this is related to an int/unsigned problem as in:
| 
| 2001-03-02  Peter Schmid  <schmid@snake.iap.physik.tu-darmstadt.de>
| 
|         * include/bits/istream.tcc: change type of __extracted to __size_type 
| 
| 
| As pointed by Benjamin, the change
| 
| 2001-02-11  Gabriel Dos Reis  <gdr@codesourcery.com>
| 
| 	* include/bits/char_traits.h char_traits<char>::int_type: Change
| 	to `int' to match 21.1.3.1/2.
| 
| 	* testsuite/21_strings/char_traits-int_type.C: New test.
| 
| seems to have non trivial repercussions.
| 
| Here the problem is that the following code (from
|   template<typename _CharT, typename _Traits>
|     basic_istream<_CharT, _Traits>&
|     operator>>(basic_istream<_CharT, _Traits>& __in, _CharT* __s):
| in istream.tcc):
| 
| 	    int_type __num = static_cast<int_type>(__in.width());
| 	    if (__num <= 0)
| 	      __num = basic_string<_CharT, _Traits>::npos;
| 
| assume that __num is unsigned.
| 
| The following patch corrects the problem mentionned above, but it 
| looks like the implications of Gaby's patch need to be looked at 
| closely.

Certainly, I think the very question is why we're playing cast game
between int_type and streamsize: I don't think there is any
requirement that every int_type represent every value of type
streamsize. Why __num isn't of type streamsize?  And __extracted should
also be of type streamsize.  Objections?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com