http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45841
--- Comment #16 from David Krauss <potswa at mac dot com> 2010-10-05 00:24:35 UTC --- (In reply to comment #15) > r164528: > ... > read(4, "1", 1) = 1 > lseek(4, 4294967295, SEEK_CUR) = 4294967303 > write(4, "x", 1) = 1 > write(4, "\n", 1) = 1 > lseek(4, 0, SEEK_CUR) = 4294967305 > read(4, "", 1) = 0 > read(4, "", 1) = 0 > lseek(4, 0, SEEK_END) = 4294967305 > ... > > r164529: > ... > read(4, "1", 1) = 1 > lseek(4, 0, SEEK_CUR) = 8 > lseek(4, 4294967295, SEEK_CUR) = 4294967303 > write(4, "x", 1) = 1 > write(4, "\n", 1) = 1 > lseek(4, 0, SEEK_CUR) = 4294967305 > read(4, "", 1) = 0 > read(4, "", 1) = 0 > write(2, "assertion \"", 11assertion ") = 11 The failure had nothing to do with the additional seek. The excerpts above show that the added operation didn't move the file pointer… the failure occurred at the same position as success before the patch. What the testcase ends up doing is extending the file and then reading past EOF. That's not illegal behavior and the case as written should still pass after comparing EOF == EOF, just as it did before my patch. Hmm, yep, caught a bug in my patch! Thanks!
