[Patch] Fix libstdc++/11722

[Paolo Carlini]

Hi Nathan,

and, first, sorry for not having explained in detail these details of my 
code,
thus wasting at least part of your time.

>Sorry for being late with this, but isn't
>
>+	   if (__avail == 1)
>+	     *__s = *this->gptr();
>+	   else if (__avail > 1)
>+	     traits_type::move(__s, this->gptr(), __avail);
>+	   __s += __avail;
>+	   this->gbump(__avail);
>+	   __ret += __avail;
>+	   __n -= __avail;
>
>a bit too precious?
>
Definitely! But...

>  Maybe 
>
>  if (__avail != 0)
>    {
>      traits_type::copy(__s, this->gptr(), __avail);
>      __s += __avail;
>      this->gbump(__avail);
>      __ret += __avail;
>      __n -= __avail;
>    }
>
>This way it doesn't waste time checking __gptr < __egptr again
>when __avail == 1, and doesn't waste time adding zeroes to __s,
>__ret, and __n when __avail == 0.  A really smart optimizer 
>might do part of that transformation, but it seems clearer not 
>to depend on it.
>  
>
We have *very* consistent evidence that special casing the single char case
leads to much better performance (at least with the current optimizers):
remember the *impressive* improvement we got in basic_string

    http://gcc.gnu.org/ml/libstdc++/2004-04/msg00096.html

?
This leads to the most important source of "uglyness" in the code...

>We are at least certain that the target __s doesn't overlap the 
>buffer, so traits_type::copy suffices, and ought to be faster.
>
This is (even) more subtle: indeed, I wanted to use copy. Then, i considered
the possibility of a user provided buffer (via setbuf), which he can 
control and
access directly. In that case, as a matter of QoI, I think we should 
allow the user
to carry out some strange tricks, i.e., calling sgetn with a pointer inside
his setbuf-ed get area. That crazy user expects, I think, the semantics 
of move.
What do you think? Shall we allow that kind of weird code?

Thanks again for your feedback,
Paolo.