Re: testsuite/27_io/filebuf.cc is nonportable

[Benjamin Kosnik <bkoz at cygnus dot com>]

As I stated in the ChangeLog entry, I believe the
22_locale/ctype_char_members.cc fail to be more significant. However, this
particular fail is still a valid problem, however.

> I have some more info today, after looking into things more closely:  The
> BUFSIZ in question comes from "/usr/include/stdio.h" and is being used by
> "libstdc++/bits/fstream.tcc" to set "_M_buf_size" which is (eventually) used to
> set the size of the input buffer on "fb_01" in "filebuf.cc".  It is implicitly
> referenced around line 198 in "filebuf.cc" when it calls fb_01.in_avail() to
> set "strmsz_1".  On Solaris this returns 1010.  On Linux it returns 8178.  (I
> had these backwards yesterday.)  Things go downhill from there, as "filebuf.cc"
> then uses this value to read five more than that many bytes from the file and
> expects the next character to be an 'i'.

Okay. Really, this test is predicated on a buffer of 8192 bytes. Yeah,
it's lame, but I had to pick a number so I could test
overflows/underflows. 

The real solution would be to force filebuf to have 8192 bytes on solaris,
or come up with a derived filebuf that has 8192 bytes, or replace the
underlying streambuf with the correctly-sized one.  I can't look at this
right now, but feel free to experiment.

> One obvious workaround it to place 'i' characters at both locations in the
> input file.  Another would be to rewrite the test so it expect a 'i' if
> "strmsz_1" was 8178, or a 't', if it was 1010.

No. Let's come up with a general solution.

> In any case, the test should check that "strmsz_1" has an expected value, so it
> can fail cleanly when it isn't.  Otherwise you'll have to revisit this as soon
> as libstdc++ is ported to a system with a different BUFSIZ.

Agreed.