[v3] libstdc++/38678

[Paolo Carlini]

Hi Martin,
>> In other terms, my current reading of the discussion / resolution of DR
>> 165 [CD1] implies that the recent changes to the ostream od libstdc++-v3
>> should be reverted, ie, ostream::write can call streambuf::sputn.
> That's my take on it as well.
Ok, excellent.
>> Moreover, since there is agreement about the istream counterpart, that
>> would imply that the istream changes should be reverted too, ie,
>> istream::read/readsome can call streambuf::sgetn. Then, to avoid back
>> and forth in the behavior we are implementing, I would think all the
>> recent changes should be reverted and libstdc++/38678 suspended.
> IMO, xsgetn() would be virtually useless if istream weren't
> allowed to call it (via sgetn()). Unfortunately, the current
> spec doesn't allow it. I'd like to think it's a defect and
> as I already mentioned will propose to relax the requirement
> to permit it.
Exactly, agreed.
> I don't know what the libstdc++ policy is, i.e., whether to
> implement strictly the word of the standard, or whether it
> is to implement only the parts that are uncontroversial and
> allow subtle (or not so subtle) deviations when they are
> thought to be beneficial or expected to be incorporated
> into the next version of the spec. So I can't very well
> comment on whether reverting the istream part of the patch
> is the right approach to dealing with the issue. FWIW,
> though, if the library is being tested with third party
> conformance test suites then I would expect the policy to
> be to strictly follow the spec (perhaps in strict mode,
> if there is such a thing) so as to minimize the number
> of failures.
Ok, thanks for your advice. Well, all in all, since we have been using
sgetn "forever", really for many years, and we have a good sensible
agreement about the direction we want to go in the standard, for now I
think I will just revert the istream changes too.

Thanks,
Paolo.