[v3] libstdc++/38678

[Martin Sebor]

Paolo Carlini wrote:
> Paolo Carlini wrote:
>> I just read carefully the discussion of 165 and I found it interesting:
>> Dietmar read 27.6.2.1/2 as requirements about *indirect* calls (e.g.,
>> sputn calling the xsputn virtual), thus not as something which has
>> immediate implications for public vs protected and friendship and so on.
>> Thus, I wonder if implementing the resolution of DR 165 implies already
>> that ostream::write is allowed to call sputn (and therefore any
>> overridden xsputn). Note that by default xsputn *is* explicitly
>> equivalent to a series of sputc, thus I don't see major inconsistencies.
>> See also where Dietmar discusses rdbuf->pubsync() vs the sync virtual...
>>   
> 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.

> 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.

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.

Martin