http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45841
--- Comment #28 from David Krauss <potswa at mac dot com> 2010-10-05 19:35:17
UTC ---
(In reply to comment #26)
> lseek(4, -1, SEEK_CUR) = -1 EINVAL (Invalid argument)
> read(4, "// 990117 bkoz\n// test functiona"..., 1023) = 1023
>
> So, it's (error/EOF) file state state that's lost; looks like I have to amend
> the check_v3_target_fileio some more and fix another simulator bug. Film at
> 11.
I'm a little confused. Is that supposed to be a sticky state? The file is
trying to seek past the beginning, not past the end, so the read should
succeed, right?
The program should terminate immediately without reading after the seek fails.
We have basic_file_stdio.cc
return lseek(this->fd(), __off, __way);
returns to seekoff in fstream.tcc
off_type __file_off = _M_file.seekoff(0, ios_base::cur);
if (__file_off != off_type(-1))
... escape scopes
return __ret; // only ever assigned pos_type(off_type(-1))
returns to pbackfail in fstream.tcc
else if (this->seekoff(-1, ios_base::cur) != pos_type(off_type(-1)))
{
__tmp = this->underflow(); // read 1024, SHOULDN'T GET HERE
else return __ret; // equal to EOF
So the code path looks sterling to me, yet it reads 1024.
Perhaps the fixed simulator is now reporting a 32-bit return value from lseek
but the the program is actually using a 64-bit, zero-extended value that
doesn't indicate failure?
