Re: [RFA:] Stricter libstdc++ testsuite gate for working target file I/O

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> First but incidentally, we never did any useful target file I/O
> in the the check_v3_target_fileio gate, we just tried to open
> "." and seek to 0 (a nop at best; could also be construed as
> invalid).  The test-suite does actual file I/O gated by that
> '// { dg-require-fileio "" }' line: reading, writing, seeking,
> so I think the gate function should try that, using the same
> machinery as the actual tests.
>
> Several tests require a working lseek primitive.  I think it's
> easy enough to get seeking with a negative offset wrong in a
> simulator(*) that it's worth testing for that.  Also, the
> generic framework for the lseek syscall in the GNU simulators at
> src/sim has a bug causing an invalid seek, like backwards from
> position 0, to return 0 instead of properly yielding an error.
> (I have patches for those simulator bugs, upcoming on
> gdb-patches@, and I'll delay committing this patch until those
> patches are applied.)
>   
The approach makes sense, in general. My only doubt is that I don't
think we want to add the gate to a large part of the test files in
27_io/basic_filebuf, essentially. Can't we skip the entire set at once,
like we do for wchar_t or thread testcases, and leave the gate for those
specific tests which are really sensitive to an lseek fully functional?
I'm adding in CC people interested in this gate in first place...
> The bugs at this PR didn't stop there (with this one in the
> test-suite, two simulator bugs and actually also one in
> libstdc++ proper ironically found by the buggy simulator; a
> patch has already been posted to add a properly "working"
> testcase IIUC).
It's already in actually ;)

Paolo.