Re: [PATCH] libstdc++/6648

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <3CE0B6EF.6020007@unitus.it>,
Paolo Carlini<pcarlini@unitus.it> writes:

> I completely agree with you that we must strieve for non-interactive 
> tests, which everyone runs by default. However, the particular version 
> you provided does not work very well for me with both 3.1, 3.1 + my 
> patch and Icc.

OK, I understand the timing nature of this failure better now.  The
issue is only seen when a character is pending but not resolvable to
either EOF or a real next character.  There is no easy non-interactive
version of the test.  I hacked on it for some time without any luck...

> Can you possibly work on refining it?

More generally, the standard and/or QoI concerns dictate proper
interleaving between tied istream and ostream.  We need a framework to
test all these timing and tying issues; and that should better cover
the untested interactive cases.

Here is one technique I have thought about: if we could replace
lowest-layer read(), write() for various tests; we could study the
proper interleaving pattern of calls.  I also wanted this technique to
automate detection of bad OS system call usage. (i.e. the test cases
where you have to run under truss, ktrace, strace, etc).

> In the meanwhile, if Benjamin agrees with the fix itself, I will commit 
> it together with the interactive :-( tests...

Anyways, while attempting to construct such a test (without using the
advanced technique still unavailable), I reviewed the standard text,
and think your patch is obvious for QoI reasons, if not also for
correctness reasons (since this issue is not related to the stream tie
mechanism, I'm not willing to cite a standard passage).

By my reading of the standard text, a caller that does not use the
return value of snextc() may always replace it with a call to sbumpc().
If the return value is actually used, then of course this is not true.

Since I consider this an obvious fix now, I'd say install it on
mainline and queue it for 3.1.1.  If I'm wrong, then I'll take the
heat for approving it. ;-)

Regards,
Loren