interesting mainline failures, 2/2

[Loren James Rittle]

Given Mark's intention to cut a branch ASAP once various PRs are
resolved motivated me to look at outstanding failures...

assertion "c == '2'" failed: file "/usr/users/rittle/outside-cvs-src/gcc-mainlin
e/libstdc++-v3/testsuite/ext/stdio_filebuf/char/10063-2.cc", line 46
FAIL: ext/stdio_filebuf/char/10063-2.cc execution test

This one is affecting many platforms.  I see c == -1...
Rebuilt to allow debugging reveals...

[...that I'm so glad we bother to support these "wonderful" extensions,
which blow a massive hole through the abstraction layer...]

Anyways... this is not a portable sequence IMHO (Linux might be the
only system to attempt to support it):

Use FILE*, making calls which populates libc's cache from file (as the test
case does).  Then later attempt to do (upon first sbumpc call):

217           __ret = read(this->fd(), __s, __n);

This does not honor libc's cache (well, it may on some systems).  You
have bypassed it completely (on most systems).  Thus, on many systems,
read() will return 0 (EOF) in this test case (since 234 already in libc's
cache and FD held within FILE* already pointing at EOF).

This is a regression from GCC 3.2.3 & 3.3.3.

Who keeps breaking these portability assumptions?  ;-) If you want to
share libc's cache (at this test case attempts to test), then AFAIK
*you* must call fread and friends instead against the captured FILE*.

It is unlikely that I will be able to fix this before the 3.4 release
but it is a regression on many primary platforms.

Regards,
Loren